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Iterative serialisation procedure for stroctured software objects 



This invention concerns an iterative procedure for conversion 
of structured software objects into a raw data flow and vice versa, 
5 providing for their direct transfer using simple communication 
facilities such as those of an embedded computer station, and reset 
of said software objects or reutilisatlon of memory space allocated to 
them. 

10 Within an application progranmied in a high-level language, 

and in particular in structured or object-oriented languages such as 
Java®, a large proportion of the data used or processed is organised 
and stored in the form of software objects with a precise stmcture, 
more complex than a simple sequence of bytes. Such objects can 

15 contain a number of variables or data groups, for example in the form 
of simple types, such as characters ("char" type) or integers ("int" 
type), or basic object types or types defined by the programmer, 
character strings ("string" type), or arrays ("array" type) with one or 
more dimensions of the types defined above. Structured objects of 

20 this type can therefore be defined or represented by a tree structure 
grouping various objects themselves of varying types, the 
organisation of a structure of this kind sometimes being referred to 
as the object composition graph. An object type can be defined "by 
Inheritance" fi-om the definition of another type (generally referred to 

25 as a "super-type"), and all types can be represented in the form of a 
tree structure referred to as the inheritance graph. 

According to the particular case, it can be usefixl to be able to 
transfer, create or delete software objects handled by a computer 
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appUcatlon, in hardware or software environments where these 
functions are not always possible or practical. 

For example, numerous computer applications incorporate 
communication between a computer terminal and possibly a 
5 computer network on the one hand, and a portable object or 
embedded platform with data processing capabilities, such as a bank, 
telephone subscription or health care management smart card, or a 
computerised identification, marking or toll device on the other. 

Such portable objects incorporate, in particular, a processor 
10 associated with storage devices, containing at least one application 
program and with facilities for communication with one or more 
terminals. These commimication facilities are based for example on a 
transnaission of electronic data using diflferent types of technology, 
such as electrical contacts, radio antenna, luminous or other forms of 
1 5 transmission, it being possible to combine a mmiber of different types 
of transmission in the same portable object. For dimensional and in 
some cases historical reasons, the commxmication facilities regularly 
employed operate with simple protocols such as the APDU protocol to 
standard ISO 7816 for smart cards. Some of these protocols only 
20 provide for the transfer of simple type objects (in the form of Integers 
or simple characters) as control parameters transmitted to or received 
In response from the object, or only at the initiative of the terminal or 
both. In the case of the ISO 7816 standards, the APDU protocol only 
allows transfer of objects without types in raw data form, as bytes 
25 sent to the computerised portable object as control parameters, or 
obtained in response firom the object, and only at the initiative of the 
terminal. 

In the current state of their evolution, some of these portable 
data processing objects such as JavaCard® incorporate internal 
30 functions, enabling them to exploit programmed appUcation elements 
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directly in high-level or object-oriented languages such as Java®, and 
to be integrated in centralised or distributed applications 
communicating on an esrtended basis. To commtmicate with 
appUcations located inside an embedded platform of this type, the 
5 programmer of such an application must avoid using structured 
software objects, or provide for direct processing, and on a case-by- 
case basis, of the transfer of these objects to and from this embedded 
platform. 

To take full advantage of the performance and the flexibility of 
1 0 a language of this type when programming an application which can 
be executed in the processor of a portable object of this type, it Is 
consequentiy useful for the application to be able to commimicate 
easily with other applications external to the object. It is therefore 
useful in this context, for the application to be able to exchange the 
1 5 objects it processes, without any loss of organisation or structure for 
these objects, with said external applications. 

In progranraiing languages such as Java®, the procedures 
used for serialisation/deserialisation of structured objects can rely on 
substantial hardware and software resources. Hiese procedures are 
20 used in particular to save a structured object to a file, or transmit a 
structured object between two program processes executed in two 
different working memory fields. 

These procedures nevertheless require software and hardware 
resources which are not available In certain embedded platforms, 
25 including Javacard® in particular. For example, the base classes 
used by a conventional Java platform occupy more than 1 MB of 
memory space (Java Developpement Kit: 9 MB), while a standard 
Javacard smart card only has 16 kB memory capacity. 

Conventional serialisation procedures use the conventional 
30 resources of the Java envirormient, and their algorithms are designed 
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with the ajms of easy utilisation and computer-managed 
maintenance. They are consequently much more memory-greedy and 
much too complex for transposition to an embedded platform with 
such limited performance In terms of memory capacity and processor 

power and speed. 

Furthermore, with Java for example, the serialisation 
procedures use a generic object type manager, implemented in the 
Java virtual machine CVM) executed on each hardware platform. 

Due to the degree of concision necessary for adaptation to an 
embedded platform, the current versions of the Javacard 
environment do not Incorporate type managers. A serialisation 
procedure such as that used in a standard Java configuration would 
not therefore have access to information representing the structure of 
the structured objects to be reconstituted from data received in APDU 
15 format. 

Furthermore, in a conventional computer envirormaent. 
memory facilities are such that the serialisation procedures 
implemented in object-oriented programming languages, such as 
Java, are not concerned with the size of the structured objects to be 

20 transmitted. The objects to be transmitted are serialised by the 
sender independently from thefr reception by the addressee, and the 
objects received can be deserialised by the addressee independently 
from the sender or the time of thefr transmission. Linear data 
streams are then transmitted and managed between sender and 

25 addressee by sofbvare mechanisms exterior to the programming 
envfrormient. These streams can thus transit via high capacity 
buffers, and are managed by other software layers, for example by a 

protocol such as TCP/IP. 

In the case of an embedded platform, the software 
mechanisms used to enable data exchange with the exterior do not 



30 
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provide stream management functions ensuring the integrity and 
continuity of the data transmitted- Nor do the modest memory 
resources of an embedded platform make it possible to store linear 
streams, and consequently large objects, during transmission and 

5 conversions. 

One of the objectives of this invention is consequently to 
propose a procedure enabling the progranmier of an appUcation using 
an embedded platform, to have access to automated software tools 
enabling a software agent, or application element, stored or executed 
10 in a portable object of this type, to receive from or send to another 
agent, situated in another computer station, data organised in the 
form of structured software objects, in a case where the 
communication facilities between sender and receiver do not allow 
transfer of the structures composing said objects as such, but only to 
1 5 transfer data tn a simpler form, and where the software and hardware 
resoin-ces of this embedded platform are not sufftcient for enabling 
the use of a conventional serialisation procedure. 

This objective is achieved by means of a data conversion 
procedure which can be used by a computer station, or embedded 
20 platform, comprising a portable object incorporating at least a 
processor, storage facilities, and communication facilities capable of 
exchanging information with a terminal in the form of one or more 
linear data sequences, characterised in that it incorporates a data set 
conversion step, in one direction or another, between a linear data 
25 sequence arrangement on the one hand, and a stmctured 
arrangement, describing or representing one or more software objects 
structured or hierarchised according to the criteria of an object- 
oriented programming language on the other. 

According to a particularity of the invention, the procediure 
30 includes the following steps: 
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- conversion, or serialisation, of a first data set to be transmitted, 
incorporating or representing one or more software objects, 
structured or hierarchlsed according to the criteria of an object- 
oriented programming language, from a structured arrangement 

5 describing or representing this object to a linear data sequence 
representing this first data set; 

- transmission of this linear data sequence using communication 
facilities, from the embedded platform to at least one host, namely 
a terminal or computer station connected to the terminal, or from 

1 0 this host to the embedded platform; 

- conversion after transmission, or deserialisation, of this linear 
data sequence to a data set arranged in one or more structured 
soflware objects reproducing or representing the first data set. 

According to a particularity of the invention, the host terminal 
15 sends Information to the embedded platform using a software agent, 
referred to as a transmission function, said Information being 
received in the embedded platform by a response ftmction which can 
initiate processing of these data by at least one addressee sofl^vare 
agent stored in the embedded platform, and forming part of at least 
20 one application, the procedure incorporating the following steps: 

- reception by a conmiunicatlon agent representing the addressee 
agent, of a data set received by the response function for said 
addressee software agent, said data set being arranged in a linear 
data sequence; 

25 - conversion of this data set into at least one software object. 

structured or hierarchlsed according to the criteria of an object- 
oriented programming language; 

- transmission of this structured soflware object to the addressee 
agent, and initiation of a processing, according to said object, by 

30 said addressee agent. 
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According to a particulariiy of the invention, the procedure 
Incorporates the following steps: 

- reception by the response function from the host transmission 
function, of at least one data Item In the form of at least one 

5 transmission parameter, and transmission of this parameter to a 
communication agent stored or executed in the embedded 
platform; 

- conversion, or concatenation, by the commxmication agent of at 
least one transmission parameter, transmitted by the response 

10 agent, into a data set arranged in a linear data sequence, and 
storage of these data in an input stream in the embedded 
platform; 

- conversion, or deserialisation, by a serialisation agent, stored or 
executed in the embedded platform, of at least part of the data 

15 stored in this input stream into a data set comprising or 
representing at least one structiured software object; 

- reception of this structured software object or its references by the 
addressee agent. 

According to a particularity of the Invention, the procedixre 
20 incorporates the foUowtng steps: 

- transmission of a stmctured software object, or its representation, 
from a software agent forming part of an application ^ecuted or 
stored in an embedded platform, to a serialisation agent executed 
or stored in said embedded platform; 

25 - conversion, or serialisation, by said serialisation agent of said 
stmctxired software object into a data set arranged in a linear data 
sequence, and storage of these data in an output stream in the 
embedded platform; 

- conversion by a communication agent, stored or executed in the 
30 embedded platform, of at least part of the data stored in this 
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output Stream into a set of response parameters suitable for 
transmission by the response function; 
- transmission of these response parameters from the embedded 
platform to the host terminal by the response function, on Its own 
5 initiative or in response to the host terminal transmission 
function. 

According to a particularity of the Invention, the linear data 
sequence stored in the input stream or output stream represents one 
or more software objects, structured or hierarchised using one or 
10 more data items referred to as tags, having one or more given values 
each representing a given action to be executed on deserialisation of 
said bnear data sequence. 

According to a particularity of the invention, at least one tag is 
defined as representing one of the foUowing actions: 
1 5 - addition of a new element to the structure of the structured object 
represented by the linear data sequence; 

- reference to an element or object, referred to as source object, as 
being source of the value of all or part of an element maldng up 
the structured object; 

20 - indication that the following data item or items represent the 
content of an element making up the structured object; 

- indication of the absence of content for an element making up the 

structured object. 

According to a particularity of the Invention, the serialisation 
25 agent serialises a structured object, referred to as soiurce object, into 
a linear data set in accordance with a procedure, referred to as 
seriaUsation procedtare. processing at least one of the objects, 
referred to as elements, making up the structure or tree structure of 
this structured source object, by the following steps: 
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- detection by the serialisation agent of the type of an element, 
referred to as current object, making up the structure or tree 
structure of said structured object; 

- storage in the output stream of a data item representing a tag 
5 indicating the addition of a new element, followed by a data item 

representing the type of the current object; 

- storage in the output stream, following the elements already 
present in the stream, by a serialisation agent, of the type 
associated with the type of the current object: 

10 ■ either by means of a data Item representing the value of aU or 
part of the structured object, 
- or by means of a data item representing a tag indicating a 
reference to an object as soiirce of the value of all or part of the 
structured object, said tag being followed by a data item 
1 5 identifying said sotirce object. 

According to a particularity of the invention, the serialisation 
procedme converts a structured object to the output stream, storing 
the type of each current object in a memoiy stack, referred to as type 
stack, the locations of which are read in reverse order to their order 
20 of storage, by successive iterations of the procedure. 

According to a particularity of the Invention, the serialisation 
agent deserialises a linear data set into at least one structured result 
object, by means of a procedure, referred to as deserialisation 
procedm-e. which processes each of the data items stored in the input 
25 stream, by the following steps: 

- read by the serlaUsation agent of at least one data item stored in 
the input stream following the data previously processed; 

- analysis of this data item and implementation of an action 
corresponding to this data item. 
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One of the objectives of the invention is also to propose a 
structured object transfer procedure of this type, making it possible 
to transfer software objects between a host and embedded platform, 
where the operating environment of said embedded platform does not 
5 Incorporate type manager for said structured objects. 

This objective is achieved by the data conversion procedure 
described above, characterised in that the deserialisation procedure 
includes the loading of an element, referred to as current object, 
namely assignment of a direct or indirect value to all or part of said 
10 current object, said element making up all or part of the structure of 
the structured result object, the termination of loading the current 
object initiating: 

- read of a data item representing an object type stored in the next 
location of a memory structiure. referred to as type stack, and 

1 5 deletion of said data item from this location; 

- storage, as the type of a new current object, of the type 
represented by the data read from the type stack. 

According to a paiticxilarity of the invention, the structured 
object created by the deserialisation procedure is considered as 
20 complete, and transmitted to the software agent or the appUcation 
which is the addressee when the type stack is empty. 

According to a particularity of the Invention, the 
deserialisation operation corresponding to a data item representing a 
tag, referred to as "NEW tag and indicating a new element, comprises 
25 the following steps: 

_ read of at least one subsequent data item in the input stream; 

- storage of the object type represented by this subsequent data 
item, in a memory stack, referred to as type stack, following the 
types being possibly already stored in this stack. 
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Accordiiig to a particiilaiity of the ixivention, the type of stack 
used by the deserialisation procedure comprises a UFO type stack, 
that is to say a stack where the locations are read In reverse order to 
the order in which they were stored. 

5 According to a parUcularLty of the invention, the 

deserialisation procediu-e comprises a step for creation of an element 
maklQg up the structure of the structured result software object, by 
allocating a new memory space or reuse of a free allocation, said 
creation being performed by a type manager agent corresponding to 

10 the type of the element to be created. 

According to a particularity of the Invention, the creation step 
for an element making up the structure of the structured result 
software object occurs between the read step of a data item indicating 
the creation of this eleinent, and the first loading step for said 

1 5 element. 

According to a particularity of the invention, the action 
corresponding to a data item, referred to as simple data item, namely 
a data item not representing a tag. Includes a step for storage of the 
value of this data item ta the memory space allocated to the current 
20 object. 

Accordrag to a particularity of the invention, during the 
deserialisation procedure, an object index is attributed to at least one 
element making up the structure of the structured resxdt object, said 
object index identifying said element uniquely, and making it possible 
25 for the element to be designated or referenced by other objects or 
elements. 

According to a particularity of the invention, the action 
corresponding to a data item representing a tag, referred to as "REF" 
tag indicating a reference, comprises the following steps: 
30 - read of at least one subsequent data item in the input stream; 
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- storage in the memoiy space aUocated to the current object, 
foUowlng the data items already stored, of a data item designating 
an object as source of the value of all or part of the ctirrent object, 
said source object or element being identified by said subsequent 

5 data item- 
According to a particularity of the invention, loading of the 
current object is considered to be terminated when the data stored in 
the memoiy space allocated to said object corresponds to a given 
length, said length being read from card memoiy by a type manager 

10 agent, or a manager agent for the types stored in the embedded 
platform. 

According to a particularity of the invention, transmission of a 
linear data sequence of a given length by the embedded platform to 
the host, is performed by an iterative procediire, referred to as data 
1 5 read procedure, comprising the foUowtag recursive steps: 

_ transmission by the host of a commvmication command including 
at least one transmission parameter representing the length of the 
data already received; 

- reception by the embedded platform of the transmission 
20 parameter, and comparison with the linear data sequence to be 

transmitted; 

- response to the communication command by transmission of at 
least one return parameter representing the data item or items 
following Immediately after the data already received by the host; 

25 - reception by the host of the communication command return 
parameter, and storage of the data which this represents following 
the data already received. 

According to a particularity of the invention, reception by the 
embedded platfoim of a linear data sequence of a given length from 
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the host, is executed following an iterative procedure, referred to as 
data write procediu^, comprising the following recursive steps: 

- transmission by the host of a commimication command with at 
least a first transmission parameter representing the data item or 

5 items foUowlng immediately after that part of the linear data 
sequence to be transmitted which has already been sent and, 
where appropriate, a second transmission parameter representing 
the position in the sequence to be transmitted, of the data 
represented by the first transmission parameter or the length of 
1 0 the data already transmitted; 

- reception by the embedded platform of the commimication 
command transmission parameter or parameters; 

- storage in an input stream in the embedded platform of the data 
represented by the first transmission parameter, following the 

1 5 data already received. 

According to a particularity of the invention, the data write 
procedure also comprises the following steps: 

- comparison by the embedded platform of the second transmission 
parameter, and comparison with the length of the data already 

20 received; 

- return by the embedded platform of at least one response 
parameter, representing either the length of the data already 
received, or a data item representing the result of this comparison, 
or both. 

25 

One of the objectives of the invention is also to propose a 
structured object transfer procedure of this type, making it possible 
to transfer software objects of a substantial size in relation to the 
possibilities of the communication facilities in terms of transfer or 
30 temporary storage, or software objects of unlimited size- 
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-nils objective Is achieved by the data conversion procedure 
described above, characterised In that at least two serialisation, 
deserialisation, data read or data write procedures are executed in 
paraUel or interleaved by repeating a step comprising successive 
5 execution of at least one step of each of these procedures. 

According to a particxjlarity of the invention, the input stream, 
output stream or both are stored in the form of circular memory 
structures, the two streams sharing possibly the same circtdar 
structure. 

10 According to a particularity of the invention, the embedded 

platform has a programmable envlromnent capable of storing and 
executing at least one appUcation created by a programmer, the 
commxmication function being compatible with the APDU format 
defined in standard ISO 7816. 

15 According to a particularity of the invention, the 

deserialisation and consequent processing operations for an object 
received are initiated on reception of at least one APDU format 
command containing at least one data item indicating reception of a 
structured object. 

20 According to a particularity of the invention, the embedded 

platform has a programmable environment compatible with the 
JavaCard® standard. 

According to a particularity of the Invention, at least one of the 
applications executed on the host or embedded platform is 

25 programmed in Java® language. 

According to a particularity of the invention, the procedure is 
used for commimlcation between at least one software agent, referred 
to as card agent, stored or executed in the embedded platform, and at 
least one software agent, referred to as card engine proxy agent, 

30 stored or executed in at least one host belonging to a computer 
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network commmiicating by asynchronous messages using an AAA- 
MOM type software infrastructure, said card engine proxy agent 
serving as an intermediary for the card agent for its coromunicatlons 
with other agents in said network, said agents operating in 

5 accordance with the specifications of said software infrastructure and 
belonging to at least one distributed application. 

Furthermore, in certain environments or operating systems, 
for example of the embedded type such as JavaCard®, there is no 
procedure, or only complex procedixres which are costly in terms of 

10 resources, for deleting a software object of this type when it is no 
longer used, or to free the memory space which it occupies. Manual 
deletion is consequently required in this case, and must be provided 
for directly and on a case-by-case basis by the application 
programmer. 

15 One of the objectives of this invention is consequently to 

propose a procedure which provides the programmer of an embedded 
platform-based application, with software tools allowing reutilisatlon 
of memory space occupied by all or part of certain structured 
software objects used by an application in a data proqesstng station, 
20 whether portable or not. 

It can also be useful to have software tools for simple 
duplication of a software object with a non-linear stmcture, for 
example in tree structure form. 

One of the objectives of this invention is consequently to 
25 propose a procedure providing the programmer of an embedded 
platform-based application with software tools for duplication of a 
structured software object, referred to as source object, to another 
object, referred to as result object, containing the same values as the 
source object but constituting a different object in storage. 



wo 03/073390 



PCT/IB03/00763 



16 

Likewise, for reasons of secxirity. when memory space 
occupied by a software object of this type is freed, it can be important 
to erase information from this object from said space, to prevent said 
information being read by another object or another application using 

5 the same memory space subsequently. This Information must 
therefore be erased manually, provision for this function being made 
directly and on a case-by-case basis by the application programmer. 

One of the objectives of this Invention is therefore to propose a 
procedure providing the programmer of an embedded platform-based 

10 application with software tools for erasing or uniformising 
Information contained in the memoiy space used by a software object 
of this type, on deletion of said object or reutilisation of said space. 

The invention consequently proposes a procedure as described 
above, characterised in that the data read, data write, deserialisation 

15 and serialisation procedvures are applied via their implementation in 
at last one class stored in the host or embedded platform, said 
implementation involving at least one of the following commands: 

- an object write command, executing transmission of a structured 
object to at least one agent of the embedded platform, by 

20 utilisation of the serialisation procedure for tiiis object, foUowed by 
the data write procedure and the deserialisation procedure; 

- an object read command, executing read of a structured object 
from at least one agent of the embedded platform, by utilisation of 
the serialisation procedure, followed by the data read procedin^ 

25 and the deserialisation procedure; 

- a deallocation command for a structured object stored in the 
embedded platform, by utilisation of the serialisation procedure, 
the latter also Including a step for storage of freeing or de- 
allocation of the memoiy space allocated to each component of 

30 said object, following analysis of the structure of said component; 
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- a housekeeping or erase command for a memory space freed by a 
structured object, by utilisation of the deserialisation procedure to 
create an object with non-material content from a given linear 
data sequence; 

5 - a duplication command for a structured source object by 
utilisation of the serialisation procedure, without deallocation of 
said source object, to create a Unear data sequence representing 
this object, foUowed by utilisation of tiie deserialisation procedure 
from this linear data sequence, to create another structured object 
1 0 the content of which is identical to that of the source object. 

According to a particularity of the Invention, the programming 
language for the embedded platform comprises a first class (lOApplet) 
describing an ProcessAPDU abstract method Initiating a process 
which can be user-defined in the appUcation on reception of an APDU 
15 message; the program code executing the deserialisation operations 
in the embedded platform being stored in the embedded platform, for 
implementation of this ProcessAPDU abstract method, in a second 
class (ObjectlOApplet) Inheriting from the first dass (lOApplet), said 
program code using a ProcessObject method, the latter being 
20 desCTibed as an abstract method in this same implementation class 
(ObjectlOApplet). 

According to a particularity of the invention, the programmi ng 
language for the embedded platform includes a first class COApplet), 
describing a SendAPDU method transmitting an APDU format 
25 message to the host; the program code executing serialisation 
operations ta the embedded platform being stored, for 
implementation of at least one SendObject method using the 
SendAPDU method, in a second card class (ObjectlOApplet) inheriting 
from the first class (lOApplet). 

30 
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Aaother objective of the iavention is to propose a computer 
system including a portable object and software tools of the types 
described above- 

This objective is achieved with a computer system comprising 
5 a computer station, referred to as embedded platform, comprising a 
portable object incorporating at least a processor, storage facilities 
and conmiunication facilities capable of exchanging Information with 
a terminal in the form of one or more linear data sequences, 
characterised In that the platform Incorporates a serialisation agent 

10 capable of executing a conversion step for a data set in one direction 
or the other, between a Linear data sequence arrangement on the one 
hand, and a structured arrangement describing or representing one 
or more software objects, structured or hlerarchised in accordance 
with the criteria of an object-oriented programming language, on the 

1 5 other. 

According to a particularity of the invention, the embedded 
platform includes a communication agent capable of: 

- receiving, tn place of the addressee agent, a data set received by 
the response function for an addressee software agent stored in 

20 the embedded platform, said data set being arranged in one or 
more linear data sequences; 

- converting this data set into at least one software object, 
structured or hlerarchised in accordance with the criteria of an 
object-oriented programming language; and 

25 - transmitttng this structured software object to the addressee 
agent, and initiating processing by the addressee agent according 
to this object. 

According to a particularily of the invention, the linear data 
sequence representing a structured software object is stored in the 
30 embedded platform in an input or output stream, said embedded 
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platfonn incorporating a software agent, referred to as serialisation 
agent, capable of creating the structxired object or objects 
represented by the input flow in the embedded platform, namely 
deserialising said structured objects, or writing data representing the 
5 structured object or objects to be transmitted to the output stream, 
namely serialising said structured objects. 

According to a particularily of the invention, the input or 
output stream is stored in the form of one or more circular memory 
structures. 

10 According to a particularity of the invention, the serialisation 

agent uses a memory stack, referred to as type stack, to store the 
type of at least one object making up all or part of the structure of a 
structured object to be serialised or deserialised, said type stack 
having a number of memory locations which can only be accessed 

15 after the memory locations loaded most recently have been read and 
erased. 

According to a particularity of the invention, the data 
contained in the input or output stream represents one or more 
structured objects, using a coding system comprising a set of tags. 
20 each of said tags representing a given action to be executed on 
deserialisation of the linear data sequence. 

According to a particularily of the Invention, at least one tag is 
defined as representing one of the following actions: 

- addition of a new element to the structured object structure 
25 represented by the linear data sequence; 

- referencing an element or object, referred to as soiu-ce object, as 
the source of the value of all or part of an element making up the 
structured object; 

- indication that the following data item or items represent the 
30 content of an element making up the structured object; 
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- indication of the absence of content for an element making up the 
structured object. 

Accordiag to a particularity of the invention, the embedded 
platform comprises a portable object operating in accordance with 
5 standard ISO 7816 and using APDU format commands. 

According to a particularity of the Invention, at least one agent 
or appUcation stored in the embedded platform is programmed in 
Java® language, said embedded platform having a computer 
enviroimient in accordance with the JavaCard® standard. 
10 According to a particularity of the invention, the system 

incorporates, in the host, embedded platform or both, at least one 
software dass implementing at least one of the foUowing commands: 

- an object write coimnand. executing transmission of a structured 
object to at least one agent of the card, by serialisation of this 

15 structured object into a data stream in the host followed by 
transmission of this data stream to the embedded platform, and 
deserialisation of said data stream into a structured object in the 
embedded platform; 

- an object read command, executing read of a structured object 
20 from at least one agent of the card, by serialisation of this 

structured object into a data stream In the embedded platform, 
followed by reception of this data stream from the embedded 
platform and deserialisation of said data stream into a structured 
object in the host; 

25 - a deallocation command for a structured object stored in the 
embedded platform, by serialisation of said object in accordance 
with an option comprising freeing or de-allocatlon of the memory 
space allocated to each component of this object, following 
anafysis of the structure of said component; 
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- a housekeeping or erase command for a memory space freed by a 
structured object in the embedded platform, by deserialisation of a 
given linear data sequence to create an object with non-material 
content; 

5 - a command for duplication in the embedded platform of a 
structured object, referred to as source object, by serialisation to a 
linear data sequence representing the same object, without 
deallocation of said source object, followed by deserialisation from 
this linear data sequence into another structured object the 
1 0 content of which is identical to that of the source object. 

According to a particularity of the invention, the embedded 
platform communicates at least with a host belonging to a computer 
network commimicating by asynchronous messages in accordance 
with an AAA-MOM type software infrastructure, said host 
15 incorporating a software agent, referred to as card engine proxy 
agent, capable of managing commtmications between said embedded 
platform and other agents of said network, said agents operating in 
accordance with the specifications of this software infrastructure, 
and belonging to at least one distributed application. 

20 

The invention and its characteristics and advantages wUl be 
miderstood more clearly by reading the following description, with 
reference to the appended diagrams where: 

Figure 1 is a partial diagram showing object transfer 
25 and conversion for read and write operations of a 

host or terminal to and from a software agent in an 
embedded platform, in a version of the invention 
where the card incorporates one application only; 
Figure 2 is a more detailed diagram of object 
30 transfer and conversion for read and write 
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operations of a host or terminal to and from a 
software agent in an embedded platform, in a 
version of the invention where the card has one 
application only; 

5 - Figure 3 is a partial diagram showing object transfer 

and conversion for read and write operations of a 
host or terminal to and from a software agent in an 
embedded platform, in a version of the invention 
where the card Incorporates a number of 

10 applications; 

Figxire 4 is a partial diagram showing the objects 
and agents involved in deserialisation of a 
structured software object from a data stream; 
Figure 5 is a partial diagram showing the objects 

15 and agents involved In serialisation of a structured 

software object to a data stream. 

In certain literature (for example "Java embarque" - Eyrolles - 
Paris 1999), the term "embedded computer" is used to designate a 
20 computer which is not visible per se. as it is integrated in an item of 
equipment possessing another ftinction. The French term "ordinateur 
embarque" is an approximate translation of the English "embedded 
computer". 

This characteristic, namely provision of a particular function 
25 within another device, largely explains the fact that such embedded 
computers frequently have only limited hardware or software 
resources, and frequently employ a rudimentary operating system or 
software environment. While enhancement is predictable, the 
resotirces of computers of this type can be typicaUy of the order of 
30 512 kb static storage down to a much lower figure, for a 8-bit or 16- 
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bit processor. In the case of a smart card, available RAM capacity can 
be of the order of 4 kb, and currently up to 32 kb for the most 
powerful models. 

In the general IT context, the term "platform" refers to a data 
5 processing device Incorporating at least a processor and storage 
facilities. By extension of the above definition, and for purposes of 
description in this context, the term "embedded platform" is used to 
designate a portable object Incorporating a platform of this type, said 
object being genuinely portable or of small size, or possessing very 
1 0 limited processing or storage capabilities. 

The following description explains the procedure according to 
the Invention for versions with given task and operation distribution 
between the various agents and applications concemed. The flexible 

15 organisation of a computer application naturally means that this 
distribution can be presented differently, in particular where 
distinctions between the various agents and their designations are 
abstract notions having no impact on their main operating 
characteristics. It is therefore obvious that the procedure according to 

20 the invention can also be Implemented in other versions not 
described here, without deviating from the basic purport of the 
invention, in particular by combining the diverse variants presented 
for each task or agent in different ways. Likewise, abstract 
distribution of tasks between agents or applications stored in the 

25 same place at the same time, can also be combined in diverse variant 
versions not described here, without deviating from the basic purport 
of the invention. 

Hie procedure according to the iavention is illustrated, in the 
30 following description, principally in the case of an embedded platform 
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comprising a smart card using a JavaCard® type system 
environment, commimicating with a terminal comprising a data 
processing station executing an appUcation programmed in Java® 
language, 

5 It is however obvious that the procedure according to the 

invention can be applied to other environments, the data 
transmission functions of which do not provide for transmission of 
structtxred software objects in a mode which is transparent for the 
programmer. Smart cards to standard ISO 7816, using another 

10 programming environment, for example 'Windows for Smart 
Cards® or which can be programmed using another programming 
language, for example Visual Basic®, can also be concerned. This 
also applies to smart cards complying with another standard 
Involving similar limits in regard to their commimication functions, or 

1 5 portable objects or terminals using a platform of this type. 

The procedure can also be applied to any portable objects 
incorporating an embedded data processing station, whether portable 
or not, such as an electronic automobile component, identification 
marker, cellular telephone or portable acquisition terminal, for 

20 example. 

Likewise, the procedure according to the invention will be 
illustrated principally as involving the utilisation of an embedded 
platform commimicating with a data processing station, referred to as 

25 terminal or host. This procedure can naturally also be used in a case 
where the terminal is a station forming part of any type of computer 
network, without deviating from the basic purport of the Invention. 
Thus, the various functions presented as being executed by this 
terminal can also be distributed between a number of dlfiferent 

30 devices, and this distribution can vary in time. Naturally, the 
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procedure described can also be described In a case where the 
embedded platform communicates directly or Indirectly with one or 
more other embedded platforms, again without deviating from the 
basic purport of the invention. In general terms, the host or host 
5 terminal wffl consequentfy be defined as the application or station 
communicating with the embedded platform. 

The procedure according to the Invention can be applied, in 
particular, to communication between a smart card, for example to 

10 the JavaCard® standard, and a computer network, for example 
programmed in Java®, communicating by means of asynchronous 
messages in accordance with an AAA-MOM type software 
infrastructure. In this case, communications between the card and 
the remainder of the network are typically managed by a software 

15 agent, referred to as card agent proxy agent, serving as an 
intermediary for each of the software agents, referred to as card 
agents, stored in the card. In the card environment, these card agents 
are managed or coordinated or both, by a software agent referred to 
as card engine agent. 

20 The procedure according to the invention then enables this 

card engine agent to communicate with the card engine proxy agent, 
exchanging structured software objects in accordance with Java 
language or AAA Infrastructure standards. The fact of bong able to 
exchange structured objects with the exterior thus enables the card 

25 to achieve enhanced compatibihty with the AAA infrastructure, and to 
be seen by the other AAA agents of the network as an AAA type agent 
itself. 

The procedure according to the invention can also be appUed 
30 to communication between a smart card, for example to JavaCard® 
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standard, and a computer network, for example programmed in 
Java®, communicating by means of an object-oriented RFC (Remote 
Procedure Call) protocol, for example with a JavaRMI (Remote 
Method Invocation) or CORBA® type software infrastructure. 

5 

Where an application requires transfer of software objects 
from a terminal to an embedded platform comprising a smart card, 
transfer often takes the form of a master/slave type commimlcation. 
This means that the terminal takes the initiative for executing a 

10 transmission function to the embedded platform. To communicate, 
this function sends a commimication command to the platform 
accompanied by transmission psirameters. This command can then 
initiate one or more processing operations in the platform, and 
receive retum or response parameters from the platform. 

15 In the case of a smart card operating in accordance with 

standard ISO 7816, the parameters of this coromand are transmitted 
in an APDU (Application Protocol Data Unit) type format, comprising 
a data sequence organised as follows: 



20 



Transmission parameters sent with the command: 



Header 


Body 


CLA 


INS 


PI 


P2 


Lc 


DataT 


Le 



25 



CLA: 

INS: one byte designating an instruction to be executed. 

PI, P2: two bytes providing information concerning the APDU 

command. 

Lc: length of data transmitted. 

Data: data transmitted. 

Le: length of retum data awaited. 
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Response parameters returned by the card: 



Bodjr 


End 


DataR 


SWl 


SW2 



Data: response data- 



SWl, SW2: two bytes constituting check messages or codes sent by 
the card. 

5 

It will be seen that this APDU format does not provide for 
transmission or reception of data in any other form than a linear data 
sequence, namely a simple byte string. When an appUcation is 
programmed In a language, or for an embedded platform for which 

10 the system does not have any other command than APDU 
commtmicatlon commands, the progranmaer wishing to transfer more 
fully stmctured objects consequently has no simple software tools for 
the purpose. The programmer is then obliged to make provision in 
the application for conversion of structured objects of this type into a 

15 byte string, then using the APDU command to transmit the string 
and finally reconverting said objects in the opposite direction. This 
corresponds to manual serialisation, transmission and deserialisation 
of said objects, in other words programming of these operations in 
the smallest detail. 

20 In the case of a programmer using Java® language for 

development of an appUcation using JavaCard® standard embedded 
platforms, the tools available in JavaCard® provide for linear data 
transmission in APDU format using the foUowing JavaCard® 
commands: 

25 - "process(APDU)": the card receives data in APDU format, and 
initiates processing of the transmission parameters which they 
contain, by the addressee software agent or "applet" designated 
in these data; 
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- "sendAPDUO" or "APDU.sendbytesO": before or during the 
process previously initiated, the card returns other data in 
APDU format and containing return parameters to the host. 

5 The "sendAPDUO" command is implemented in the JavaCard 

environment in the "lOApplet" class, in the form of a method 
applicable to a non-typed object containing raw data. 

The "Process(APDU)" command on the other hand is declared 
tn the "lOApplet" class in the JavaCard environment, in the form of 

10 an abstract method. This means that the method exists in the 
Javacard enviroimient, but also that the code implementing the 
method must be written by the programmer of an application for 
which it is desired to use this command. For example, the 
programmer creates an taherlting sub-class of the "lOApplet" class in 

15 the application, this sub-class then containing a method receiving the 
code of the process to be executed by this "Process(APDU)" method. 
The JavaCard enviroimient merely calls the "ProcesslAPDU)" method 
when a message is received, and then initiates the process which the 
programmer has Included tn the additional code. 

20 

To provide a programmer in this context with the tools for 
direct transmission of structured software objects, the procedtare 
according to the invention provides similar commands, but which 
accept structured software objects directly, in accordance with the 

25 specific object-oriented characteristics of the Java® language. These 
commands can then be used in the JavaCard® environment, and can 
be of the "process(Object)" and "sendObjectO" type, for example. 

To enable the prograromer, also referred to here as the user, 
to employ these commands directly without having to become 

30 involved with APDU command syntax, the procedure according to the 
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invention takes over serialisation, transmission and deserialisation 
operations for objects and data between the application or sender 
agent and the addressee agent. 

In the case of a JavaCard environment, these operations can 

5 be performed by executing a program code contained in the 
"Process(APDU)" method belonging to a sub-class of the "lOApplet" 
class, named "ObjectlOApplet". for example. This code is then 
initiated automatically by the environment when an APDU message is 
received, and itself contains the conversion operations and the call to 

10 another "Process(Object)" abstract method. With a version of the 
invention of this type, the progranmier merely has to write the code 
for the operations to be executed by the card when a structured 
object is received. The programmer then writes this code in an 
inheriting sub-class of the "ObjectlOApplet" class, for implementation 

15 of the "Process(Object)" abstract method. 

Only the conversion, serialisation and deserialisation 
operations executed at the card end are described in the following 
paragraphs. It is naturally clear that the procedtire described can 

20 also be used for executing the same operations at the host end. The 
hardware and software resources of the host terminal being usually 
substantially greater than those available on the card, these 
operations can nevertheless also be programmed or organised 
differently at the host end without deviatiag from the basic purport of 

25 the invention. 

In a version of the invention represented in Figure 1, a host 
terminal (1) communicates with an embedded platform, for example a 
Javacard® standard smart card (2). Host (1) executes at least one 
30 application (1 1) comprising at least one software agent (111), and 
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communicates with card (2) by means of an APDU fonnat 
conraiunication function (101), involving conomunication resources 
including a connection location (100), for example. This connection 
location incorporates a means of coxmectlon, for example by electrical 
5 contact, microwave link, IR link or magnetic track, or a combination 
of two or more of these types. 

Card (2) executes an application (22) including at least one 
software agent (221), and communicates with the host (1) using a 
response function (201) forming part of the JavaCard® system 

10 environment. For this purpose, said response function (201) uses 
communication resources (200) of a type compatible with the 
communication resources (100) of host terminal (1). 

When agent (111) of host appUcation (11) wishes to send data 
to card agent (221), order it to execute a process (2210) or request 

15 Information located In card storage, it executes an object write 
instruction initiating the procedure for sending structured software 
object (31) to the card, this instruction being designated 
^WriteObjectO", for example. Said software object (31) is then 
serialised, namely converted to an APDU format data set by a host 

20 conversion agent (12), This host conversion agent then uses the 
commiuiication function (101) to transmit these data to the card (2) 
via the host connection location (100) and the card communication 
resources (200). 

When received in the card by the response function (201) 

25 which manages the commimication resources (200), this response 
function transmits said data to a card conversion agent (21). Said 
card conversion agent (21) deserialises the data, converting them in 
the opposite direction to reobtain their original structure, in the form 
of a software object (34). Said structured software object (34) is then 

30 transmitted to the addressee agent (22), using an object processing 
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Instruction which will execute the process (2210) corresponding to 
the data received, this instruction being designated "Process(Object)", 
for example. 

When the agent (221) of application (22) In card (2) wishes to 
5 send data to the agent (111) of host (1). or information concerning a 
process executed, it executes an object transmission instruction 
which initiates the procedure for transmission of a structured 
software object (41) to the host, this instruction being designated 
"SendObjectO", for example. Said software object (41) is then 
10 serialised, namely converted to an APDU foraiat data set, for example 
by the card conversion agent (21). This card conversion agent then 
uses the response function (201) to send these data to the card (2) via 
the card communication resources (200) and the host connection 
location (100). 

15 When received by the host commxmication function (101) 

which manages the connection location (100). said commimication 
function transmits the data to the host conversion agent (12). Said 
host conversion agent (12) deserialises the data, converting them in 
the reverse direction to reobtain their original stmcture in the form of 

20 a software object (44). Said structured software object (44) is then 
transmitted to the addressee agent (11) by an object read instruction 
which reads the data received, this Instmction being designated 
"ReadObjectO". for example. 

25 Figure 2 represents a version of the invention where 

serialisation/deserialisation and transmission operations executed by 
the host and caird conversion agents (12 and 21 respectively), are 
executed by two different agents (121, 122 and 211, 212 respectively). 
The card conversion agent (21) thus comprises a 

30 commxmication agent (211) and a serialisation agent (212). The 
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communication agent (211) manages the byte conversion operations, 
exchanging data In the form of transmission parameters (32) and 
response parameters (43) with the response function (201). For data 
reception, said conmiunication agent (211) veriflLes that the data 

5 received are complete, and concatenates transmission parameters 
(32) in a linear data sequence stored in an input stream (33). For data 
transmission, said communication agent (211) reads a linear data 
sequence in an output flow (42), and separates these data for 
distribution as response parameters (43) compatible with the 

1 0 transmission capabilities of the response function (201). 

The serialisation agent (212) manages the object level 
conversion operations, performing serialisation/deserialisation 
proper. For data transmission and consequently serialisation, the 
serialisation agent (212) analyses the structure and content of a 

15 structured software object (41) to be transmitted, and codes this 
object in the form of a linear data sequence stored in the output 
stream (42), For data reception and consequently deserialisation, the 
serialisation agent (212) reads a linear data sequence in the Input 
stream (33). It then analyses the data in this stream, and 

20 reconstitutes the structured software object (34) which they 
represent. 

Figure 3 represents a version of the invention where the card 
can have a number of agents (221, 222, 223, 231) which can have 

25 addressee status for the procedure according to the invention, these 
agents being possibly distributed between one or more appUcations 
(22, 23). To be able to handle all data exchanges between the card (2) 
and the host (1), the procedure according to the Invention includes an 
interface agent (210), via which all structured data exchanges 

30 between the card (2) and the host (1) transit. 
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In this version of the invention, the interface agent (210) 
receives all data transmitted to the card, in place of the application 
(22) or addressee agent (221). irrespective of said addressee. Said 
interface agent (210) then directs concatenation of transmission 
5 parameters (32) by the commimication agent (211), and subsequent 
deserialisation of resultant data (33) by the serialisation agent (212), 
as described above. Once these data have been reconstituted as a 
structured software object (34), the same interface agent (210) 
transmits said structured object (34) to the software agent (221) 

10 which was the addressee for data (32) on their reception. In another 
version (not shown), the data (32) received by the interface 
agent (210) contain identification information for the addressee agent 
(221), or the interface agent (210) adds corresponding information to 
said data (32) before these are transmitted. The structured object (34) 

15 resulting from deserisdisation is then addressed directly by the 
deserialisation agent (212) or a distribution agent (not shown). 

In the same way, the interface agent (210) receives aU data 

(41) transmitted to the host by a sender application (22) or a sender 
agent (221). Said interface agent (210) then directs serialisation of 

20 these data, by the seriahsatLon agent (212), into an output stream 

(42) , and concatenation of said output stream (42) by the 
commimication agent (211), as described above. The data obtained 
are then sent by the response function (201) to the terminal (1) via 
the communication resources (200, 100) in the form of response 

25 parameters (43). 

In another version of the invention (not shown), the interface 
agent (210) is inserted in the transmission and conversion chain 
(201, 211, 212, 221). For reception in the card (host write command), 
the interface agent (210) directs the data or objects received to their 

30 addressee (221, 222, 223, 231) in the card, according to information 
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included in the data received. For transmission from the card (host 
read command), the interface agent (210) can also be included to 
receive data or objects to be transmitted, assigning information to 
said data or objects representing their sender (221. 222. 223, 231). 

5 

It can be considered that information exchanges between the 
host (1), whether this is the terminal itself or any software agent 
capable of managing this terminal, and an agent or application 
present on the card, are consequently executed at two different levels, 

10 namely byte level and object level. 

At object level, the data organised in structured software 
objects to be transmitted are converted into a Unear data stream, and 
vice versa. This serialisation step manages the structure of the object, 
and is executed by the seriahsation agent in each platform. 

15 At byte or byte string level, the data arranged in simple linear 

streams are transmitted by fragment using the transmission 
function, for example in APDU format, this being the only means of 
exchanging information between the card and the outside world. 
These exchanges are managed by the host and card co m m u ni c ation 

20 agents, which commimicate with each other by sending parameters 
using this trginsmission fimction. 

To provide the user with transparent commands, the various 
processes are implemented in one or more classes, and generally with 
at least one operating in the card and one in the terminal or host. In 

25 Java® language, the procedure according to the invention can so 
provide an "ObjectlOApplet" class for the card and an "ObjectlOProxy" 
class for the host, using the following syntax: 
class ObJectlOProxy { 

void writeObJect (Object o); 

30 Object readObJect 0; 
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} 

With the * ObjectIOProxy" class defining a class In the host, providing 
the user application with "writeObject (Object)" and "readObJect 0" 
commands: 
5 class ObjectlOApplet { 

void process (Object o); 

void sendObject (Object o); 

} 

and with the "ObjectlOApplet" class defining a class in the card, 

10 providing the user application with "process(Object)" and 
"sendObjectO" commsmds. 

As the card is essentially passive, all these conversion and 
transmission operations are executed at the initiative of the host, 
using an instruction in the code which triggers transmission of an 

15 APDU cormnand. It Is this command that initiates the conversion 
operation requested firom the agent concerned. 

When executed in the card application code, the 
"process(Object)" and "sendObjectO" commands do not therefore 
trigger the corresponding conversion operations directly. The 

20 "sendObjectO" command stores the object to be transmitted in an 
output queue, for example "qout", where the objects to be serialised 
for transmission are introduced by an Introduction command of the 
"qout.push(object)" tj^e. When a serialisation operation is initiated, 
these objects to be transmitted are extracted from the output queue 

25 in the same order as they were introduced. 

Likewise, the command extracts an object serialised by a 
previous operation initiated by the host, from an input queue, for 
example "qtn". Said extraction is obtained by an extraction command 
of the "qin.popO" type. 

30 
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The read, write, serialisation and deserialisation operations 
are then managed from the host by the "ObjectlOProsgr" class, using 
user-transparent commands. These commands can be Implemented 
in the code of this class, In the following form for example: 
5 - "card.Serialize out": initiates serialisation in the card of the object 
to be transmitted, as described below. These objects can have 
been stored in an output queue on execution of a "sendObJectO" 
instruction by the card application; 

- "card.Read": initiates output stream data read in the card, and 
1 0 transmission of these data to the host, as described below; 

- "card, Write": initiates transmission of data to the card, and data 
write to the input stream, as described below; 

- "card.Serialize In": initiates deserialisation of the objects present in 
the input stream in the card, as described below. 

15 

In the version of the invention described here, the card output 
and input streams are stored in the same circular memory structure. 
Other versions of the invention are naturally possible, using a 
different memory structure for each stream or using other types of 

20 memory structtire. 

A circiilar memory structure corresponds in this case to a set 
of successive memory locations, the first location being considered by 
the system as following immediately after the last location. This 
means that a linear data sequence can be stored in a structure of this 

25 tjrpe starting at any location, without loss of continuity, provided the 
length of said sequence is not greater than the total nixmber of 
locations. 

The fact that the input and output streams share the same 
circular structure involves storing the data which they contain in 
30 different areas of this same circular structure. The data contained in 
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these streams being erased as they are read, immediately or during 
an operation, the length and position of the two streams vary inside 
this circular structure. When one of the two streams has no more 
space to store new data as it is blocked by non-erased data of the 

5 other stream, it is merely necessary to process the other stream to 
free the space which it occupies. 

A circular structure of this type makes it possible to use 
limited storage resources for processrag streams the length of which 
is not determined in advance. It Is merely necessaiy for the different 

10 operations on the two streams to be interspersed sufficiently evenly 
for this purpose- 

At byte level, data exchanges from a platform output stream to 
the input stream of the other platform, and vice versa, are executed 
15 as described below. 

If the host wishes to obtain data located in the card output 
stream, it sends a read command, for example "card.Read" for Java® 
syntax. This command initiates a read session, typically divided Into 
20 a number of transactions, each transaction representing one iteration 
of the process. 

To initiate the read session, the host issues an APDU format 
command, accompanied by transmission parameters (PI and P2, 
corresponding to a short integer) representing the length of the data 

25 which it wishes to receive, via its commuunication agent and 
transmission function. On receipt of this command from the 
communication agent, the card reads a first data block in the card 
output stream, and transmits this block to the card response 
frmction. This first data block is then returned to the host as 

30 response data (DataR) in the response to the APDU command. 
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Each successive iteration of the read process then Involves 
transmission of an APDU command by the host, accompanied by 
transmission parameters (PI and P2, namely a short integer) 
representing the length of the data already received. Once received by 

5 the card communication agent, this length serves as an 
acknowledgement for previous transmissions. Thus. the 
commimicatlon agent retums the output stream data Immediately 
following the length Indicated by the host, as response data patal^. 
It should be noted that data are read from the output stream but are 

10 not erased, and can consequently be retransmitted in case of need. 
This means that no data can be forgotten in this transmission. 

The read session terminates when the length requested by the 
host has been received correctly, and the host stops the iterations. 
The session can also be terminated, or interrupted, if the card 

15 commimicatlon agent sends a data item (for example, a DataR field 
with zero length) or a code (SWl or SW2) signifying that all available 
data in the output stream has already been sent. If the card output 
stream is empty, the host must then initiate a new object 
serialisation operation from the card "qout" queue to the card output 

20 stream, in the card, for the output stream to receive fresh data. 

When the host wishes to transmit data from its oul^jut stream 
to the card, it sends a write command, for example "card.Write" for 
Java® syntax. Tills command initiates a write session, typically 
25 divided into a number of transactions, with each transaction 
representing one process iteration. 

To initiate the write session, the host sends an. APDU format 
command, accompanied by transmission parameters (PI and P2, 
namely a short integer) representing the length of the data it wishes 
30 to transmit, via its communication agent and transmission function. 
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The data field (DataT) of this first APDU command then contains the 
first data block or group to be transmitted, this data block being read 
in the host ou^ut stream. On receipt of this command, the card 
response fimction transmits said first data block to the card 

5 communication agent. The card communication agent then writes 
this first data block to the card input stream. 

Each successive iteration of the write process involves 
transmission of an APDU command by the host, accompanied by 
transmission parameters (PI and P2, namely a short integer) 

1 0 representing the length of the data already transmitted. The data field 
(DataT) of this first APDU command then contains the next data 
block or group read firom the host output stream. On receipt of this 
command, the card response function transmits these parameters 
and this data block to the card communication agent. The card 

15 coramimication agent then compares the data length annoimced in 
the transmission parameters (PI and P2) with the length of the data 
already received since the beginning of the write session. This means 
that no data can be forgotten in this transmission. 

If this comparison identifies no errors, the card 

20 commimication agent writes this data block to the card input stream. 
If an error is detected, the commimication agent returns a code or 
index to the host, indicating an error and/or representing the nature 
of this error. This code or index can be returned via the response 
parameters (SWl and SW2) of the response function, the returned 

25 data field (DataJR). the length of this field or a combination of these 
elements. 

The write session terminates when the length armoim^ced by 
the host has been transmitted, and the host stops the iterations. The 
session can also be terminated, or interrupted, if the card 
30 commxmicatton agent sends a code or index indicating that the card 
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input stream cannot receive any fresh data. The host must then 
initiate one or more operations in the card for freeing space in the 
memory structure containing this input stream. 

This can involve initiating in the card a new data 
5 deserialisation operation from the input stream to the "qtn" Input 
queue of objects accessible to the card application. This can also 
iQvolve initiating a new read session to receive data contained in the 
card output stream, and thus free space in the circular structure 
containing the two streams. 

10 

At object level, serialisation and deserialisation operations are 
executed between the data streams and agents or applications of the 
card, and vice versa, as follows. 

15 Objects are deserialised in the card from input flow (33) to the 

"qin" input queue, where they are directly accessible to the 
"Process(Object)" instruction, provided by the "ObjectlOApplet" class 
and used by the addressee agent or application. 

For implementation of the procedure according to the 

20 invention, the host uses an instruction when it wishes to initiate a 
deserialisation operation in the card, for example "card.Serialize In" 
for Java® syntax. 

Figure 4 illustrates deserialisation of a structured software 
object (34) by decoding the data of input stream (32) corresponding to 

25 said object (34), arid storage and structure component creation 
operations for said structured object (34), or result object. 

Reading one after the other the data stored in a linear 
sequence in the input stream (33), the serialisation agent (212) 
interprets these data according to a given code, and creates a 

30 structured software object (34) based on this interpretation. Certain 
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data In the data sequence stored in this input stream can have a 
given value, and this value is Interpreted as indicating the presence of 
a code tag. This decoding can be performed by calling an allocation 
method particular to each type of structured object to be decoded, for 
5 example using the following syntax: 

Typeobjectrrdecode (Object, InputStream) 
to decode an object "Object" of type 'Typeobject", from the input 
stream "Input Stream". 

This code comprises a set of tags each having a gnren 
10 significance, and each corresponding to at least one speciftc value of 
a data item in the input stream. Thus, each data item in the input 
stream having a value corresponding to one of these tags is 
Interpreted by the serialisation agent during the deserialisation 
process- 

15 For applications using the procedure according to the 

Invention, the serialisation agent (212) can be designed to recognise a 
number of tag sets, or each tag can be represented by a nimiber of 
different data values, without deviating from the basic purport of the 
Invention. Diversity of this type can be used, in particular, for 

20 accounting for one card (2) or card type, with a number of different 
terminals or host environments. 

For the version of the invention described here, the code 
comprises tags of the "NULL", "NEW, "REF" and "DATA" type. 

- A NULL tag represents an absence of data, while occupying a 
25 location in the structure in course of construction by the 

serialisation agent. 

- A NEW tag indicates the beginning of the description of a new 
object to the serialisation agent, this object being structured 
software object (34) resulting from the conversion, or an object. 
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referred to as element, comprising part of a structured object (34) 
of this type. 

- A REF tag indicates the designation of an object, the same or 
another object, as value source for all or part of the object or 

5 element in course of description. This is used to assign a value by 
reference. 

- A DATA tag indicates that the following data represent the value or 
content of the object or element in course of description. Hiis 
content can comprise raw data representing one or more values to 

10 be assigned to the object directly, or include other tags again 
indicating objects or references defining this content. 

According to its type, a tag can be followed by one or more 
data items, interpretation of which is determined by the meaning of 
the tag concemed. 

1 5 - On reading a NEW tag, the serialisation agent knows that it must 
interpret the following data item as representing the type of the 
new object described. 

- Likewise, on reading a REF tag, the serialisation agent knows that 
it must interpret the following data item as representing an 

20 identifier for the object designated as source of this value by 
reference. 

In the version of the invention described here, the tags are 
coded on one byte in the same way as type and reference identifiers 
but it is obvious that the procedure according to the Invention also 
25 provides for the utilisation of other codes, which are different or more 
complex or explicit according to the needs and possibilities of the 
computer environment concemed. 

As it reads the data of input stream (32), the serialisation 
agent (212) analyses the value of each data item, gind creates and 
30 loads objects or elements (340, 341, 342, 343, 344) making up the 
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result object (34). This read of input stream (32) is repeated until 
reconstruction of the object (34) represented by this input stream has 
been completed. Hiis creation can be obtained by calling an 
allocation method particular to each object type, for example using 
5 the following syntax: 

lypeobject: rmallocQ 
for creation or allocation of a 'Typeobject" type object on 
deserialisation. 

As objects of this type can have dififerent structures, these 

1 0 creation and loading operations are managed, whether directly or not, 
by a management agent fTMO. TMl, TM2) of a type specific to the 
type of object to be created, for example a "type marshaUer" agent in 
Java® language. This type management agent is specific to one or 
more object types, and can be managed by a generic type manager 

15 agent flMG), for example a "type manager" agent in Java® language. 
In particular, this type manager agent stores the identifiers for the 
various object types created during the deserialisation process. This 
generic type manager agent CTMG) also includes the codes and 
procedures, or methods, specific to these different object types and 

20 used for serialisation/deserialisation of the same objects. The type 
manager agent is also used to manage the list of objects and their 
allocations, making it possible to execute new allocations and reuse a 
firee allocation to create a new object on decoding. 

Typically, the type manager agent (TMG) includes information 

25 on all the different types of object which can be managed in the card. 
This information can be generated by a host, for ex£imple during a 
card programming phase. The information is then transmitted with 
classes ("applets") used by the appUcattons, in the form of a program 
code ("glue code") which is added to the code of the generic type 

30 manager agent (TMG). 
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Using a type manager agent, and type marshaller agents as 
described below, the procedure according to the invention makes it 
possible to manage the serialisation and deserialisation of structured 
5 objects of basic or constructed type, in an embedded platform the 
programming environment of which, such as JavaCard for example, 
does not include such a type manager. 

Creation of an object or element during decoding corresponds 
10 to allocation of this object, namely reservation of given memory 
space, and allocation of this space to the object. Some embedded 
environments. Including Javacard® in particular, do not include 
software tools which can be used to free memoiy space previously 
occupied by a deleted object, such as a conventional Java® language 
1 5 "garbage collector" agent. On creation of an object by the serialisation 
agent (212), the procedure according to the invention can provide for 
the possibility of executing this creation with allocation of memory 
space to this object which had previously been occupied by another 
object which had become superfluous, for example of the same type 
20 as the object to be created. It is consequently possible to reuse card 
memory space from time to time, this frequently being a valuable 
asset due to card memory space limitations. 

In the example illustrated in Figure 4, the input stream (32) 
25 corresponds to a structured result object (34), the structure, or graph 



of which can be described in Java® language in the following form: 



Typel: {bool} 


class B (boolean bo ;} 


Type2: Typel+{int, byte, lypeO} 


class X extends B { 

int i ; 
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byte by ; 
Yy : 
} 


TVpeO: nypel } 


class Y { B b ;} 



On reading the input stream (33), the serialisation agent reads 
a NEW tag (321) first. It therefore reads the following data item (322), 
and then stores the creation request for a tj^pe 2 object. In 
5 accordance with this NEW identifier 2 tag (321), the serialisation 
agent creates new object "x" (340), of class X in the example, using 
the type manager agent frM2) corresponding to the same lype 
(Type2). At the commencement of description of a result object, this 
new object will be the "root" object of the tree structure of the graph 

1 0 for this result object. 

On this creation, the serialisation agent assigns an index 
(3402) to the newly created object (340), this index taking a value of 0 
in the example. Said index (3402) can thus serve as a reference for 
other elements or parts of elements on construction of this result 

15 object (34). making it possible to determine whether the content of 
this element has been loaded or not. 

The serialisation agent then stores the type and index of this 
object in a memory structure, referred to as type stack (TYST). This 
type stack is a memory stack type structure, which means that data 

20 items can be stored (pushed) one on top of the other, and a given 
data item can only be read and exbracted (popped) when the data 
stored subsequently have already been extracted. Data are extracted 
firom the stack in the reverse order to that in which they were stored 
(LIFO for Last In First Out). 

25 The serialisation agent also stores the type of said new object 

(340) and its index, as corresponding to the object, referred to as 
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current object (OBJ), which will be loaded with the next data in the 
input stream. 



The next tag is a DATA tag followed by two raw data items 
5 (324, 325), which are not tags or identifiers. These two data items are 
therefore stored in the current object (OBJ), namely x (340) as the 
value of the foUowing elements (342, 343). These two following 
elements are integer type (int) designated "i", and byte type (byte) 
designated "by" respectively, these elements taking the values 
10 contained in these two data items (324, 325) of the input stream 
respectively. 

The next tag is a NEW tag, followed by a data item indicating 
type 0. This sequence Indicates that the next element of object "x" is a 
type 0 object. The serialisation agent will therefore assign an index 

15 (3442), 1 in the example, to said object (344), and add (push) the 
index and type, namely 0, for said new object (344) to the type stack 
CIYSni. The serialisation agent will also have a type 0 object, 'Y (3^) 
of type Y in the example, created by type manager agent (TMO) 
corresponding to type 0. 

20 Via the type manager agent (TM2) corresponding to the 

current object (OBJ), the serialisation agent knows that said current 
object (OBJ), namely "x", is not fuUy loaded. The next tag, a DATA tag 
followed by a raw data item (329), will consequently be assigned as 
value for the next element (341) of the current object, namely as the 

25 value of Boolean type element "bo", this being the last element of 
object "X". 

Via the type manager agent frM2) corresponding to the 
current object (OBJ), the serialisation agent knows that said current 
object (OBJ), namely "x" (340), is now fully loaded. Hie tadex (3402) 
30 of said loaded object (340) is then stored in the object stack (OBJSTO, 
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With the Identifier of this object (340) in the card. The serialisation 
agent then terminates loading of the current object, and extracts 
(pops) the type and index stored at the top of the type stack flYST). 
The top of the stack must naturally be tmderstood as the stack 
5 location accessible first. The type and index extracted fi-om the type 
stack, O and 1 respectively in the example, are then stored as 
corresponding to a new current object (OBJ). 

Hie next tag is a DATA tag, which therefore indicates the 
loading of the current object, namely "y". This tag is followed by a 

10 REF tag (3211) and a data item (3312), 0 in the example. The 
serialisation agent therefore assigns a value by reference to object "y" 
(344), representing a simple link with the value of the object for 
which the index (3402) is designated by this reference (3212). Object 
'y* will therefore have a value defined as referencing object "x", which 

15 has index 0 in the deserialisation process. This link can then be 
defined in the result object (34) by storing the identifier for this object 
"x" in the card, this identifier being read fi*om the object stack 
(OBJSrn by means of this index. 

Via type manager agent flMO) corresponding to the current 

20 object (OBJ), the serialisation agent knows that said current object 
(OBJ), namely "y ". is now ftally loaded. The index (3442) of said loaded 
object (344) is therefore stored in the object stack (OBJST). with the 
identifier for said object (344) in the card. The serialisation agent then 
terminates this loading and interrogates the type stack 

25 As the tjrpe stack (TY'ST) is empty after extraction of the type 

of object "y", namely there are no more "constructed types" to be 
reconstituted, the serialisation agent concludes that the resxilt object 
(34) has been created in full. 
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In a variant version of the invention, the creation or allocation 
of a new object can be performed at any stage of the deserialisation 
process, from read of the NEW tag indicating said new object, up to 
commencement of loading of this object. 
5 In another variant, the index used on deserialisation of an 

object is identical to the identifier of the object in the card. 

Objects are serialised in the card from output stream (42) to 
output queue "qout", which can be accessed directly by the 
10 instruction " SendObjectQ" supplied by the "ObJectlOApplet" class 
and used by the addressee agent or application. 

For implementation of the procedure according to the 
invention, the host uses an instruction, for example "card.Serialize 
Out" for Java® syntax, to initiate a serialisation operation in the card. 

15 

Figure 5 illustrates the serialisation of a structured software 
object (41), referred to as source object, by analysis of the 
components of the structure of said structured object (41), followed 
by coding in the form of data stored in the output stream (42) 
20 corresponding to said source object (41). 

This serialisation function is implemented in a method, 
namely an action or procedure available for an object of a given type, 
using the following Java® syntax: 

lypeobject:: (Object, OutputStream) 
25 being a method used to code an object "Object" of type "Typeobject" to 
the output stream "OutputStream". 

Typeobject: :getSuperO 
being a method used to obtain information concerning the type and 
constructed types of an object, on coding a 'Typeobject" type object. 
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Hie basic types are generally those types scheduled and 
managed by the environment or programming language, in contrast 
to constmcted types, defibied as a combination of a number of 
objects. Current basic types are "integer'\ "Boolean" and "byte" for 
5 example for an embedded environment, and long integer, real, long 
real and character types ("long", "real", "double" and "char") for more 
comprehensive environments. 

For this serialisation operation, the serialisation agent (212) 

10 executes a recursive scan on the complete structure, or graph, of the 
sotirce object (42) to be serialised, analysing the object elements (410, 
412, 413, 414, 411), starting with the "root" object or element, "x" in 
the example. The graph of the source object (42) presented in the 
example is the same as described above for Figtire 4. The serialisation 

15 agent calls an agent (TMO. TMl, TM2) corresponding to the same 
constructed type, for each graph element having a constructed type. 

Description of the source object (41) in the output stream (42) 
commences by writing a NEW tag, followed by the root element type 
identifier, type 2 object "x" in the example. This root object is then 

20 designated as current object (OBJ). This object also receives an index, 
0 in the example, and its type and index are then loaded (push 
operation) in the type stack flYST). 

The description is continued by writing a DATA tag, followed 
by data indicating the values or references corresponding to the 

25 content of the root object. As root object "x" contains an object "y" 
(414) which is a constructed type, the description of the root objective 
includes a NEW tag, followed by the type of said object "y", "NEW 0" 
in the example, in place of the value of said object "y". An index is 
assigned to the NEW tag, 1 in the example, when this tag is written. 
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The index and type of this new object are then loaded (push 
operation) in the type stack CTYSTl. 

When description of the content of object (OBJ), namely object 
"x" (410), has been completed, the index of this object is stored In the 
5 object stack (OBJST) with the identifier of this object. The 
serialisation agent then interprets the type stack, extracting ("pop" 
operation) the type and index of object "y". It stores said object "y" as 
new current object (OBJ), and then commences description of the 
content of said object "y". This object comprising a simple reference to 
10 the root object "x". the data written to the output stream comprise a 
REF tag, followed by a data item serving as index for the object to be 
designated as reference, namely the object "x" with index 0 in the 
example. 

Once description of the content of the current object, namely 
15 object "y" (414) has been completed, its index is stored in the object 
stack (OBJST) with the identifier of this object. The serialisation 
agent then interrogates the type stack, extracting (pop operation) the 
iype of object "x"' which was stored under object "V" in this type stack. 
As the index of object "x" is already stored in the object stack 
20 (OBJST), the serialisation agent knows that object "x" has already 
been serisillsed or described. It consequentiy interrogates the type 
stack again, observes that it is empty, and consequentiy concludes 
that all elements making up the source object (34) have been fully 
described in the output stream (42). 

25 

Due to the recursivity of these algorithms, it is possible to 
perform these seriatLsatton and deserialisation operations using a 
program code which takes up sufflcienUy little memory space for it to 
be possible to store the code in an embedded platform, for example a 
30 smart card or JavaCard standard portable computerised object. The 
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concision of these algorithms also makes it possible to execute these 
operations with a low-power processor, such as those used In such 
embedded platforms. 

5 In order to balance the volume of data stored in temporary 

form, the various read, write, serialisation and deserialisation 
operations required by the host application (11) can be interleaved in 
one or more program loops. A loop of this type executes a command 
for each of these operations on each iteration, for example using the 
1 0 following Java® syntax: 
Do 

Do card.Seriallze out While (ok out) 
Do card.Read While (data read) 
While (data in) card.Write 
15 While (ok in) card.Serialize in 

Loop 

In this example, the first and last lines ("Do" and "Loop") 
determine the repetition of a loop comprising the four intervening 
Unes of code. A loop of this type can naturally be combined with other 
20 operations, and include various conditions for interrupting the 
iteration process. 

The first line in the loop indicates initiation of a serialisation 
session to the card output stream, for objects previously stored in the 
"qout" output queue by a "SendObJectO" command, in the card. This 
25 session is then repeated as long as an "ok out" condition is met, for 
example as long as there are objects to be transmitted in the "qout" 
queue, and the output stream is not fiill. 

The second line indicates initiation of a read session for data 
contained in the card output stream by the host. This session is then 
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repeated as long as a "data read" condition is met, for example as 
long as data are received from the card- 

The third line indicates execution and repetition of a write 
session to the data input stream from the host. This session is only 
5 executed and repeated if, and as long as a "data in" condition is met, 
for example as long as there are data to be sent to the card and the 
card entry stream is not full. 

The fourth Une indicates execution and repetition of a 
deserialisation session for data contained in the card entry stream to 
10 the structured object "qln" entry queue, where these data are 
extracted by a "process(Object)" command. This session is only 
executed and repeated if, and as long as an "ok in" condition is met, 
for example as long as there are data to be deserialised in the card 
entry stream. 

15 In the case of a passive card, to JavaCard® standard for 

example, the end of an object serialisation operation typically Initiates 
processing of the object, for example by automatic call to the 
"process(Object)" method. 

20 It should be noted that only operations executed at the card 

end are illustrated in this example. Symmetrical operations executed 
at the host end can be performed either in a similar or totally 
different way, according to the hardware and software resources 
available, without deviating from the basic purport of the invention. 

25 

Due to the fact that these various complementary operations 
are Interleaved in a software loop which can be repeated recursively, 
the various phases Involved in the transfer of a structured object can 
be executed in parallel, within the framework of a single execution or 
30 single transfer command. Using data streams stored in circular form. 
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and reusing the same memoiy space indefinitely, as described above, 
the same command can initiate complete transfer of a structured 
object with no restriction on size despite the limited capacities of the 
embedded platform. 

5 

Where all the conversion operations described above are 
implemented, namely programmed, in one or more procedures loaded 
in the host and the embedded platform, said procedures can then be 
accessed by the user with a few simple commands. 

10 In the version of the invention described here, as applied to 

the Java® language and JavaCard® environment, an application 
programmer only needs to use these few simple commands to create 
the application. These commands perform all intermediate operations 
transparently for the user. In other words, the user has no need to 

15 become involved with internal operation of the mechanism of said 
commands. 

For example, the "ObJectIOPro3sy" class loaded in the 
processing station or host terminal supplies the *WriteObjectO" and 
"ReadObjectO" commands. 

20 Likewise, the "ObJectlOApplet" class loaded in the embedded 

platform supplies the "Process(Object)" and "SendObjectQ" 
commands. Typically, the "ObJectlOApplet" class Implements these 
commands using a known extension technique, namely by 
inheritance from the "lOApplet" class which contains the 

25 "process(APDU)" method. This involves adding the program code 
combined with the initial method to this method, and modifying or 
replacing operation of the code as defined in the initial method. 
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Instruction "WriteObJectO" is employed by the user in its host 
application, for transmitting a stmctured object to the card 
application and tnitiatuig processing in the card. 

The "Process(Object)" method is called automatically by the 
5 card following reception and deserialisation of a structured object. 
The content of this method is then programmed by the user in that 
part of the application loaded in the embedded platform, to execute 
the desired operations from this object. Tbiis method is then used in a 
similar way to the standard "process(APDU)" command ni JavaCard® 
1 0 for APDU format data only. 

The "SendObjectO" instruction is employed by the user in that 
part of the application loaded in the embedded platform, for example 
inside the "Process(Object)" method code, to prepare transmission of 
one or more stmctured objects from the embedded platforai to the 
15 host. This instmction is then used in a similar way to the standard 
"sendAPDUO" command in JavaCard® for APDU format data only. 

The "ReadObjectO" instruction is employed by the user in its 
host application, for reception of the stmctured object or objects 
which the card application has prepared for this purpose, from the 
20 embedded platform. 

It will be understood that is easier for a programmer creating 
an application involving an embedded platform of this type, to 
transmit structured software objects between said embedded 
25 platform and a host or terminal, even if the communication resources 
of said embedded platform are not capable of transmitting data in 
byte or integer form. 

It can be useful for the programmer of an embedded 
30 application to have a few simple commands for deallocation of a 
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structured software object, or reset or erase of correspondtng memoiy 
space, as also duplication of a structured software object. This is 
particularly true in a case where the programrning environment of the 
embedded platform does not possess a garbage collector software tool 
5 managing reutilisation of memoiy space already allocated, for 
example in the JavaCard® environment. 

In a version of the procedure according to the invention, the 
analysis step for each component of a structured software object 

10 during serialisation of the object, can be performed using various 
options. A number of these options can be included in 
implementation of the same serialisation command, each execution of 
this command being accompanied by a parameter indicating which 
option must be used. These various options can also be used 

1 5 separately in dlEferent implementations of the serialisation command. 

In one of these options, on analysis of each component of a 
structured software object during serialisation of the object, the 
serialisation agent (212) deallocates the memory space containing 
this component, or marks said component as being reusable for a 

20 new allocation. Thus, serialisation using this option, referred to as 
destructive serialisation, executes conversion of a structured object 
after which the memory space occupied by the object is freed. 

In another version, the procedure according to the invention 
can include an option or command which executes this type of 

25 destructive serialisation of a structured object stored in the card, 
outside any transmission operation, for example in implementation of 
the "ObjectlOApplet" class. It will be clearly imderstood that the 
procedure according to the invention enables the user to reuse 
memory space occupied by all or part of some of the software objects 

30 of the application, without diffllculty. 
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In another version (not shown), the procedure according to the 
invention includes an option or command executing deserialisation of 
a structured object by reusing the memory space in the card 
5 previously occupied by a structured object which has since been 
destroyed, as described above. This deserialisation is executed, 
outside any transmission operation, from a data stream containing 
data which is all identical or non-material. After allocating and 
writing an object of this type, the memory space reused does not 
10 contain any data belonging to the object previously occupying the 
space concerned. When this operation is implemented, for example in 
the "ObJectlOApplet" class, the procedure according to the invention 
enables the user to program total erase of memory space 
corresponding to a given allocation without difiBlculty. 

15 

In another version (not shown), the procedure according to the 
invention includes an option or cormnand executing serialisation of a 
structured soxxrce object to a Unear data sequence, outside any 
transmission operation. Tills same linear data sequence is then 
20 deserialised into a result object identical to the source object, but 
using a different memory space. When this operation is implemented, 
for example in the "ObjectlOApplet" class, the procedure according to 
the invention enables the user to program identical duplication of a 
stmctured software object without difficulty, 

25 

It wiU be obvious to the specialist in this domain that this 
invention provides for versions in many other specific forms, without 
deviating fi:om the field of application for the invention as claimed. 
Consequently, the version described must be regarded as being 
30 provided for illustration purposes only, and can be modified in the 
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domain defined by the scope of the attached claims. The invention 
must not therefore be limited to the details given above. 
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CLAIMS 

1 . Procedure for data conversion for use by a computer station 
(2), referred to as "embedded platform", comprising a portable object 
incorporating at least a processor, storage facilities and 

5 communication resources capable of exchanging information with a 
terminal in the form of one or more linear data sequences, 
characterised in that it includes a conversion step for a data set, in 
one direction or the other, between an arrangement comprising a 
linear data sequence on the one hand, and a structured arrangement 
10 describing or representing one or more software objects, structured 
or hiersirchised according to the criteria of an object-oriented 
programming language on the other hand. 

2. Procedure according to the preceding claim, characterised 
in that it includes the following steps: 

- conversion, or serialisation, of a first data set to be transmitted, 
comprising or representing one or more software objects (31, 41), 
structured or hierarchised according to the criteria of an object- 
oriented programming language, from a stmctured arrangement 
describing or representing this object, to a linear data sequence 
representing said first data set; 

- transmission of said linear data sequence by commimication 
resources (200 or 100), from the embedded platform (2) to at least 
one host (1), namely a terminal or computer station connected to 
the terminal, or from said host (1) to embedded platform (2); 

25 - conversion after transmission, or deserialisation, of this Unear 
data sequence to a data set arranged in one or more structured 



15 



20 
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software objects (34 or 44) reproducing or representing the first 
data set. 

3. Procedure according to one of the preceding claims, 
characterised in that the host terminal (1) sends information to the 

5 embedded platform (2), using a software agent (101), referred to as 
transmission function, said information being received in the 
embedded platform by a response function (201), capable of initiating 
a process (2210) for said data by at least one addressee software 
agent (221), stored in the embedded platform and forming part of at 
10 least one application (21), the procedure including the following 
steps: 

- reception by a communication agent (211), in place of addressee 
agent (221), of a data set (32) received by the response ftmction 
(201) for said addressee software agent, said data set being 

1 5 arranged in a linear data sequence; 

- conversion of this data set into at least one software object (34), 
stmctured or hierarchised according to the criteria of an object- 
oriented programming language; 

- transmission of ssiid structured software object (34) to the 
20 addressee agent (221), and initiation of a process (2210), 

according to said object, by said addressee agent. 

4. Procedure according to one of the preceding claims, 
characterised in that it includes the following steps: 

- reception by the response ftmction (201) ft^om the transmission 
25 ftmction (101) of host (1), of at least one data item in the form of at 

least one transmission parameter (32), and transmission of this 
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parameter to a communication agent (211) stored or executed in 
embedded platform (2); 

- conversion, or concatenation, by the commimication agent (211) of 
at least one transmission parameter (32), transmitted by the 

5 response agent (201), Into a data set arranged in a linear data 
sequence, and storage of these data In an input stream (33) in the 
embedded platform (2); 

- conversion, or deserialisation, by a serialisation agent (212) stored 
or executed In the embedded platform (2), of at least part of the 

10 data stored in said input stream (33) to a data set comprising or 
representing at least one stmctured software object (34); 

- reception of said structured software object (34) or its references 
by the addressee agent (221). 

5. Procedure according to one of the preceding claims, 
1 5 characterised In that it includes the following steps: 

- transmission of a structured software object (41) or its 
representation, ft-om a software agent (221) forming part of an 
application (22) executed or stored in an embedded platform (2), to 
a serialisation agent (212) executed or stored ta said embedded 

20 platform; 

- conversion, or serialisation, by said serialisation agent (212) of 
said stmctured software object (41) to a data set arranged in a 
linear data sequence, and storage of these data in an output 
stream (42) in the embedded platform; 

25 - conversion by a communication agent (211), stored or executed in 
the embedded platform (2), of at least part of the data stored in 
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said output stream (42), to a response parameter set (43) capable 
of being transmitted by the response function (201); 

- transmission of said response parameters (43) from the embedded 
platform (2) to the host terminal (1) by the response function 

5 (201), at its own initiative or In response to the transnmssion 
function (101) of host terminal (1), 

6. Procedure according to one of the preceding claims, 
characterised In that the linear data sequence stored in the input 
stream (33) or output stream (42) represents one or more software 

10 objects (31 or 41) stmctured or hierarchised using one or more data 
items, referred to as tags, with one or more given values each 
representing a given action to be executed on deserialisation of said 
Unear data sequence. 

7. Procedure according to one of the preceding claims, 
15 characterised in that at least one tag is defined as representing one of 

the following actions: 

- addition of a new element to the structure of the stmctured object 
represented by the linear data sequence; 

- reference to an element or object, referred to as source object, as 
20 the source of the value of aU or part of an element making up the 

structured object; 

- indication that the following data item or items represent the 
content of an element making up the stmctured object; 

- indication of the absence of content for an element making up the 
25 stmctured object. 
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8- Procedure according to one of the preceding claims, 
characterised in that the serialisation agent (212) serialises a 
structured object (41), referred to as source object, Into a linear data 
set (42), following a procedure, referred to as serialisation procedure, 
5 processing at least one of the objects (410 to 414), referred to as 
elements, making up the structure or tree structure of said 
structured source object (41), by the following steps: 

- detection by the serialisation agent (212) of the type (4100). of an 
element (410, 414). referred to as current object, making up the 

1 0 structure or tree structure of said structured object (41); 

- storage in the output stream (42) of a data item representing a tag 
indicating the addition of a new element, followed by a data item 
representing the cinrent object type (TYOBJ); 

- storage in the output stream, after the elements already present in 
15 the stream, by a type serialisation agent flMO, TMl, TM2) 

associated with the current object type flYOBJ): 

■ either by means of a data item (424, 425, 429) representing the 
value of all or part (412, 413, 411) of the structured object (41), 

■ or by means of a data item (4211, 4212) representing a tag 
20 (4211) Indicating a reference to an object (410) as source of the 

value of aU or part (414) of the structured object (41), this tag 
being followed by a data item (4212) identifying said source 
object (410). 

9. Procedure according to one of the preceding claims, 
25 characterised in that the serialisation procedure converts a 
structured object (41) to the output stream (42), storing, on each 
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iteration, the type of each current object In a memory stack flYSTI, 
referred to as type stack, the locations of which are read in reverse 
order to the order in which they were stored. 

10. Procedure according to one of the preceding claims, 
5 characterised in that the serialisation agent (212) deserialises a linear 

data set into at least one structured result object (34), following a 
procedure, referred to as deserialisation procedure, processing each 
data item stored in the input stream (33), by the following steps: 

- read by the serialisation agent of at least one data item stored in 
1 0 the input stream after the data previously processed; 

- analysis of this data item and execution of an action 
corresponding to said data item. 

11. Procedure according to one of the preceding claims, 
characterised in that the deserialisation procedure involves loading 

15 an element, referred to as current object, namely assignment of a 
direct or indirect value to all or part of said current object, said 
element making up all or part of the structure of structured result 
object (34), with termination of loading of the current object initiating: 

- read of a data item (TYT2) representing an object type stored in the 
20 next location of a memory stmcture, referred to as type stack 

flYSD, and erase of this data item from this location; 

- storage, as new current object type flYOBJ), of the type 
represented by the data item frYT2) read from the type stack. 

12. Procedure according to one of the preceding claims, 
25 characterised in that the structured object (34) created by the 

deserialisation procedure is considered to be complete and 
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transmitted to the software agent (221) or application (22), which is 
addressee for said object, when the type stack {TYSTO is empty. 

IS.Procedure according to one of the preceding claims, 
characterised in that the deserialisation action corresponding to a 
5 data item (321, 326) representing a tag, referred to as "NEW" tag, 
indicating a new element, involves the following steps: 

- read of at least one subsequent data item (322, 327) ia the input 
stream; 

- storage of the object type, represented by said subsequent data 
10 item (322, 327) in a memory stack, referred to as type stack 

(TYST), following the types which may already have been stored. 

14. Procedure according to one of the preceding claims, 
characterised in that the type stack flYSTl used by the 
deserialisation procedure comprises a LIFO type stack, namely where 

15 the locations are read in reverse order to that in which they were 
stored. 

15. Procedure according to one of the preceding claims, 
characterised in that the deserialisation procedure includes a step for 
creation of an element (410 to, 414) making up the structure of the 

20 structured result software object (34), by allocation of a new memory 
space or reutilisation of a free allocation, said creation being executed 
by a type manager agent (TMO, TMl, TM2) corresponding to the type 
of the element to be created. 

le.Procedure according to one of the preceding claims, 
25 characterised in that the creation step for en element (410, 414) 
making up the structure of the structured restilt software object (34) 
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occurs between the read step for a data item (322, 327) Indicating the 
creation of said element, and the first loading step for the same 
element. 

17. Procedure according to one of the preceding claims, 
5 characterised in that the action corresponding to a data item (324, 

325. 329), referred to as simple data item, namely not representing a 
tag, includes a storage step for the value of this data item in the 
memory space allocated to the current object. 

18. Procedure according to one of the preceding clai ms , 
1 0 characterised in that, dtixing the deserialisation procedure, an object 

index (4102) is assigned to at least one element (410) making up the 
structtire of the structured result object (34), said object index 
identifying said element in a imique manner, so that said element 
can be designated or referenced by other objects or elements (414). 

15 19. Procedure according to one of the preceding claims, 

characterised in that the action corresponding to a data item (3211) 
representing a tag, referred to as "REF" tag, indicating a reference, 
includes the following steps: 

- read of at least one subsequent data item (3212) in the input 
20 stream (32); 

- storage in the memory space (3441) allocated to the current object 
(344), following data already stored, of a data item designating an 
object (340) as source of the value of all or part of the current 
object, said source object or element (340) being identified by said 

25 subsequent data item (32 12) . 
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20. Procedure according to one of the preceding claims, 
characterised in that the loading of the current object is considered to 
be terminated when the data stored in the allocated memory space 
correspond to a given length, said length being read from storage in 

5 card (2) by a type manager agent (TMO, TMl, TM2) or by a generic 
type manager agent (TMG) in the embedded platform. 

21. Procedure according to one of the preceding claims, 
characterised in that the transmission by the embedded platform (2) 
to the host (1) of a linear data sequence (42) of a given length, is 

1 0 executed according to an iterative procedure, referred to as data read 
procedure, which includes the following recursive steps: 

- transmission of a commimlcation commaind by the host, 
accompanied by at least one transmission parameter representing 
the length of the data already received; 

15 - reception by the embedded platform of the transmission 
parameter, and comparison with the linear data sequence to be 
transmitted; 

- response to the commimlcation command by transmission of at 
least one return parameter (43), representing the data item or 

20 items following immediately after the data already received by the 
host; 

- reception by the host of the communication command return 
parameter (43), and storage of the data which it represents after 
the data already received. 

25 22. Procedure according to one of the preceding claims, 

characterised in that the reception by the embedded platform (2) from 
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the host (1) of a linear data sequence (43) of a given length, is 
executed according to an iterative procedure, referred to as data write 
procedure, comprising the following recursive steps: 

- transmission by the host of a communication command 
5 accompanied by at least a first transmission parameter (32) 

representing the data item or items following immediately after the 
part of the linear data sequence to be transmitted already sent, 
and where appropriate, a second transmission parameter 
representing the position. In the sequence to be transmitted, of the 
10 data represented by the first transmission parameter, or the 
length of the data already transmitted; 

- reception by the embedded platform of one or more 
cormnxmication cormnand transmission parameters (32); 

- storage in an input stream (33) in the embedded platform of the 
15 data represented by the first transmission parameter (32), after 

the data already received. 

23. Procedure according to one of the preceding claims, 
characterised in that the data write procedure also includes the 
following steps: 

20 - comparison by the embedded platform of the second transmission 
parameter, and comparison with the length of the data already 
received; 

- return by the embedded platform of at least one response 
parameter representing either the length of the data already 

25 received, or a data item representing the result of this comparison, 
or both. 
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24.Procedure according to one of the preceding claims, 
characterised in that at least two of the serialisation, deserialisation, 
data read or data write procedures are executed in parallel, or 
Interleaved by repetition of a step including successive execution of at 
5 least one step of each of said procedures. 

25-Procedure according to one of the preceding claims, 
characterised in that the input stream or output stream, or both, are 
stored in the form of circular memory structures, it being possible for 
said two streams to share the same circular structure. 

10 26. Procedure according to one of the preceding claims, 

characterised in that the embedded platform has a programmable 
environment, capable of storing and executing at least one 
application created by a programmer, the communication function 
being compatible with the APDU format defined in standard 

15 ISO 7816. 

27. Conversion procedure according to the preceding claim, 
characterised in that deserialisation and treatment operations for an 
object received are initiated by reception of at least one APDU format 
command including at least one data item indicating reception of a 

20 structured object. 

28. Procedure according to one of the preceding claims, 
characterised in that the embedded platform has a programmable 
environment compatible with the JavaCard® standard. 

29. Procedure according to one of the preceding claims, 
25 characterised in that at least one of the applications executed on the 

host or embedded platform is programmed In Java® language. 
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30. Procedure according to one of the preceding claims, 
characterised in that the data read, data write, deserialisation or 
serialisation procedures are performed by implementation in at least 
one class stored in the host or embedded platform, said 
5 Implementation including at least one of the following commands: 

- an object write command, transmitting a structured object (31) to 
at least one agent (221) of the embedded platform, by utilisation of 
the serialisation procedure for this object, followed by the data 
write and deserialisation procedures; 

10 - an object read command, reading a structured object (41) from at 
least one agent (221) of the embedded platform, by utilisation of 
the serialisation procedure, followed by the data read and 
deserialisation procedures; 

- a deallocation command for a structured object stored in the 
15 embedded platform, by utilisation of the serialisation procediore, 

the latter also including a storage step for freeing or deallocation 
of the memory space allocated to each component of said object, 
after analysing the structure of this component; 

- a housekeeping or erase command for a memory space freed by a 
20 stmctured object, by utilisation of the deserialisation procedure to 

create an object with non-material content from a given linear 
data sequence; 

- a duplication command for a structured object, referred to as 
source object, by utilisation of the serialisation procedure without 

25 deallocation of said source object, to create a linear data sequence 

representing the same object, then by utilisation of the 
deserialisation procedure from said linear data sequence to create 
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another structxired object the content of which is identical to that 
of the source object. 

31- Procedure according to the preceding dalm, characterised 
in that the programming language of the embedded platform includes 
5 a first class (lOApplet), describing a ProcessAPDU abstract method, 
uiltiating a user-deflnable process in the application on reception of 
an APDU message; the program code executing deserialisation 
operations in the embedded platform being stored in said embedded 
platform, as Implementation of said ProcessABDU abstract method, 
10 in a second class (ObJectlOApplet) inheriting the first class (lOApplet), 
said program code calling a ProcessObject method, the latter being 
described as an abstract method In this same Implementation class 
(ObjectlOApplet) . 

32. Procedure according to the claim (Javacard), characterised 
15 in that the programming language of the embedded platform includes 

a first class (lOApplet) describing a SendAPDU method transmitting 
an APDU format message to the host; the program code executing the 
serialisation operations in the embedded platform being stored, as an 
implementation of at least one SendObject method calling the 
20 SendAPDU method, in a second class (ObjectlOApplet) inheriting said 
first class (lOApplet), 

33. Procedure according to one of the preceding claims, 
characterised in that it is used for communication between at least 
one software agent, referred to as card agent, stored or executed In 

25 the embedded platform, and at least one software agent, referred to 
as card engine proxy agent, stored or executed in at least one host 
belonging to a computer network communicating by asjmchronous 
messages according to an AAA-MOM t5^e soflware infirastructure, 
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said card engine proxy agent serving as an Intermediaiy for the card 
agent in its communications with other agents of said network, said 
agents operating in accordance with the specifications of said 
software infrastructure and belongtag to at least one distributed 
5 application. 

34. Computer system comprising a computer station (2), 
referred to as embedded platform, comprising a portable object 
including at least a processor, storage facilities and commxmication 
resources capable of exchanging information with a terminal in the 

10 form of one or more linear data sequences, characterised In that the 
platform incorporates a serialisation agent (212), capable of executing 
a conversion step for a data set, in one direction or the other, 
between a linear data sequence arrangement on the one hand and a 
structured arrangement describing or representing one or more 

15 software objects structured or hierarchised in accordance with the 
criteria of an object-oriented programming language on the other 
hand. 

35. System according to the previous claim, characterised in 
that the embedded platform (2) includes a communication agent (211) 
20 capable of: 

- receiving, in place of the addressee agent (221), a data set (32) 
received by the response function (201) for an addressee software 
agent (221) stored in the embedded platform, said data set being 
arranged in one or more linear data sequences; 

25 - converting said data set into at least one software object (34), 
structured or hieraurchised according to the criteria of an object- 
oriented programming language; 
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- transmitting said structured software object (34) to the addressee 
agent (221), and initLattng execution of a process (2210)» according 
to said object, by said addressee agent (221). 

36. System according to one of the preceding claims, 
5 characterised in that the linear data sequence representing a 

structured software object is stored in the embedded platform, in an 
input or output stream, the embedded platform incorporating a 
software agent, referred to as serialisation agent (212), capable of 
creating the structured object or objects represented by the input 
10 stream in the embedded platform, namely deserialising said 
structured objects, or writing data representing the structured object 
or objects to be transmitted in the output stream, namely serialising 
said structured objects. 

37. System according to one of the preceding claims, 
1 5 characterised in that the input stream or output stream is stored in 

the form of one or more circular memory structures. 

38. System according to one of the preceding claims, 
characterised in that the serialisation agent (212) uses a memory 
stack, referred to as type stack, to store the type of at least one object 

20 making up all or part of the structure of a structured object to be 
serialised or deseriaUsed, said type stack including memoiy locations 
none of which are accessible until the locations loaded more recentiy 
have been read and erased. 

39. System according to one of the preceding claims, 
25 characterised in that the data contained in the input or output 

stream represent one or more structured objects, using a code 
comprising a set of tags, each of said tags representing a given action 
to be executed on deserialisation of said linear data sequence. 
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40. System according to one of the preceding claims, 
characterised in that at least one tag is defined as representing one of 
the following actions: 

- addition of a new element to the structure of the structured object 
5 represented by the linear data sequence; 

- reference to an element or object, referred to as source object, as 
the source of the value of all or part of an element making up the 
structured object; 

- indication that the foUowtng data item or items represent the 
1 0 content of an element making up the structured object; 

- Indication of the absence of content for an element makin g up the 
structured object. 

41. System according to one of the preceding claims, 
characterised in that the embedded platform includes a portable 

15 object operating in accordance with standard ISO 7816 and using 
APDU format commands. 

42. System according to one of the preceding claims, 
characterised in that at least one agent or application stored in the 
embedded platform is programmed in Java® language, the embedded 

20 platform having a computer environment in accordance with the 
JavaCard® standard. 

43. System according to one of the preceding claims, 
characterised in that it Includes at least one software class in the 
host, embedded platform or both, implementing at least one of the 

25 following commands: 
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- an object write command, transmitting a structured object (31) to 
at least one agent (221) of the card, by serialisation of said 
structured object into a data stream in the host, followed by 
transmission of this data stream to the embedded platform, and 

5 deserialisation of said data stream into a structured object in the 
embedded platform; 

- an object read command, reading a structured object (41) from at 
least one agent (221) of the card, by serialisation of said 
structured object into a data stream in the embedded platform, 

10 followed by reception of said data stream from the embedded 
platform, and deserialisation of said data stream into a structured 
object in the host; 

- a deallocation command for a structured object stored in the 
embedded platform, by a serialisation of said object according to 

15 an option Involving freeing or deallocation of the memory space 
allocated to each component of said object, after analysis of the 
structure of said component; 

- a housekeeping or erase command for a memoiy space freed by a 
structured object in the embedded platform, by deserialisation of a 

20 given linear data sequence to create an object with non-material 
content; 

- a command for duplication in the embedded platform of a 
structured object, referred to as source object, by serialisation into 
a linear data sequence representing the same object, without 

25 deallocation of said source object, followed by deserialisation from 
said linear data sequence into another structured object the 
content of which is identical to that of the source object. 
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44. System according to one of the preceding claims, 
characterised in that the embedded platform communicates with at 
least one host belonging to a computer network commimlcating by 
asynchronous messages according to an AAA-MOM type software 

5 infrastructure, said host including a software agent, referred to as 
card engine proxy agent, capable of managing communications 
between said embedded platform and other agents of said network, 
said agents operating in accordance with the specifications of said 
software infrastructure and belonging to at least one distributed 

10 application. 
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Procede iteratif de serialisation d'obiets loaiciels structures 



La pr^sente invention concerne un proc6d6 iteratif de conversion 
d'objets logiciels structure en un flux de donn6es brutes et inversement. 
5 permettant leur transfert direct par des moyens de communication simples 
comme ceux d'une station Informatique embarquee, ainsi qu'une remise k z§ro 
de tela objets logiciels ou une r^utilisation de Pespace m^moire qui leur est 
alloue. 

10 Au sein d'une application programm^e dans un langage de haut 

niveau, et en particulier dans le cas des langages structures ou orient6s objets 
comme par exemple Java®, une grande part des donnees utilisees ou trait6es 
sont organis^es et memoris6es sous la fomne d'objets logiciels comportant une 
structure precise, plus complexe qu'une simple succession d'octets. De tels 

15 objets peuvent regrouper plusleurs variables ou groupes de donn6es. par 
exemple sous la fornie de types simples. caract6res (type "char"), entier (type 
"int"), ou de types d'objets de base ou d6finis par le programmeur, chaTne de 
caracteres (type "String"), ou de tableaux (type "array") ^ une ou plusieurs 
dimensions des types pr§cedemment d6finis. De tels objets structures peuvent 

20 done §tre d6finis ou representes par une ariaorescence regroupant differents 
objets eux-memes de diff6rents types. I'organisation d'une telle structure 6tant 
parfois appelee le graphe de composition de I'objet. Un type d'objet peut etre 
d§fini "par heritage" a partir de la definition d'un autre type (gen^ralement 
appele "super-type"), Tensemble des types peut etre repr6sent6 sous la fomne 

25 d'une arborescence nomm6e le graphe d'h6ritage. 

Selon les cas. il peut §tre utile- de pouvoJr transferer,, creer. ou 

supprimer les objets logiciels manias par une application infomiatique, dans 
des environnements mat6riels ou logiciels oO ces fonctionnalit6s de sont pas 
toujours possibles ou pratiques. 
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De nombreuses applications informatiques, par exemple, comportent 
une communication entre d'une part un terminal informatique et eventueilement 
un r6seau informatique. et d'autre part un objet portable ou plate-forme 
embarqu6e ayant des capacites de traitement de donnees, comme par 
5 exemple une carte d puce de gestion bancaire. d'abonnement telephonique ou 
de sant6, ou un dispositif de reperage, de marquage. ou de peage informatis6. 

De tels objets portables comportent en particulier un processeur 
associe a des moyens de memorisation, contenant au moins un programme 
d'application, et ^ des moyens de communication, avec un ou plusieurs 
10 terminaux. Ces moyens de communication sont bases par exemple sur une 
transmission d" informations 6!ectroniques par differents types de technologies, 
telles que contact 6lectrique, antenne radio, transmission lumlneuse ou autre, 
plusieurs types de transmissions pouvant etre combinees dans le meme objet 
portable. Pour des raisons d'encombrement ou part=ois d'ordre historique, les' 
15 moyens de communications utilises de fa?on courante fonctionnent selon dei 
protocoles simples, par exemple « APDU » selon la norme ISO 7816 pour le^ 
cartes S puces. Ces protocoles ne permettent parfois le transfert que d' objets 
de types simples (sous fomie d'entiers. voire de caracteres simples) en tant 
que param6tres de commande transmis a I'objet ou obtenus en r^ponse de sa 
20 part, ou seutement a Tinitiative du terminal, ou les deux. Dans le cas de la 
norme ISO 7816, le protocoie APDU ne permet que le transfert d'objets sans 
types en tant que donnees bmtes, sous forme d'octets transmis d I'objet 
portable infomnatise en tant que parametres de commande, ou obtenus en 
r6ponse de sa part, et seulement a 1' initiative du terminal. 

En !'6tat actuel de leur evolution, ces objets portables de traitement de 
donnees sont pour certains dot§s d'un fonctionnement interne, par exemple 
JavaCard®. apte & exploiter directement des elements d' applications 
programmes dans des langages de haut niveau voire orientes objet, par 
exemple Java®, et a §tre integres dans des applications centralisees ou 
distribuees communiquant de fagon 6tendue. Pour communiquer avec des 
applications situ^es S I'interieur d'une telle plate-forme embarquee. le 
programmeur d'une telle application doit alors s'abstenir d'utiliser des objets 



25 



30 



1er depot 

3 



logiciels structures, ou prevoir de traiter directement et au cas par cas le 
transfert de ces objets avec cette plate-forme embarquee. 

Pour benef icier des performances et de la souplesse d'un tel langage 
lors de !a programmation d'une application executable dans le processeur d'un 
5 tel objet portable, 11 devient done utile que cette application puisse 
communiquer facilement avec d'autres applications externes a cet objet. II est 
done utile pour cela qu'elle puisse ^changer avec elles les objets qu'elles 
fraitent, sans perte de I'organisation et de la structure de ces objets. 

Dans des langages de programmation tels que Java (marque 

10 deposee), les precedes utilises pour la serialisation ou deserialisation d*objets 
structures peuvent compter sur des ressources materielles et logicielles 
importantes. Ces proc6d§s sont utilises en particulier pour sauvegarder un 
objet structure dans un fichier, ou pour transmettre un objet structure entre 
deux processus de programme s'executant dans deux zones memoires de 

1 5 travail differentes. 

Ces precedes utilisent toutefois des ressources logicielles et 
materielles qui ne sont pas disponibles dans certaines plates-formes 
embarquees, en particulier Javacard (marque deposee), A titre d'exemple, les 
classes de bases utilisees par une plate-forme Java classique occupent une 

20 tailie memoire superieure au mega-octet (Java Developpement Kit ; 9 Mo), 
alors qu'une carte a puce au standard Javacard peut ne disposer que de 
16 kilo-octets. 

Les precedes classiques de serialisation utilisent les ressources 
classiques de Tenvironnement Java et leurs algorithmes sont conpus avec des 
25 objectifs de facilite d'emploi et de maintenance informatique. lis sont done 
beaucoup trop gourmands en memoire et beaueoup trop complexes pour 
pouvoir gtre transposes dans une plate-forme* embarquee d'aussi -faible 
performance en termes de capacite memoire et de puissance et Vitesse de 
processeur. 

30 Par ailleurs, en Java par exemple, les precedes de serialisation utilisent 

un gestionnaire g^n^rique de types d'objets (« type manager »), impl6ment6 au 
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sein de la machine virtuelle (VM) Java s'executant sur chaque plate-forme 
materielle. 

Du fait de la concision n6cessaire pour §tre adaptee ^ une plate-forme 
embarqu6e, I'environnement Javacard dans ses versions actuelles ne 
comporte pas de gestlonnaire de types. Un proced6 de serialisation tel 
qu' utilise en Java standard ne d.isposerait done pas des informations 
representant la structure des objete structures a reconstituer d partir des 
donnees regues en format APDU. 

Par ailleurs, dans un environnement informatique classique, les 
ressources en memoire sont telles que les precedes de serialisation 
impiementes dans les langages de programmation orientes objets, comme 
Java, ne se preoccupent pas de la taille des objets structures d transmettre. 
Les objets ^ envoyer sont serialises par I'emetteur independamment de leur 
reception par le destinataire, et les objets re^us peuvent §tre deserialises par le 
destinataire independamment de I'emetteur ou du moment de letir 
transmission. Les flux lineaires de donnees sont alors transmis et geres entre 
emetteur et destinataire par des mecanismes logiciels qui sont exterieurs 4 
I'environnement de programmation. Ces flux peuvent ainsi transiter par des 
zones tampons en memoire {« buffers ») de capacites importantes, et sont 
geres par d'autres « couches » logicielles, par exemple par un protocole tel que 
TCP/IP. 

Dans le cas d'une plate-forme embarquee. les mecanismes logiciels 
permettant d'echanger des donnees avec I'exterieur n'offrent pas de 
fonctionnalites de gestion de flux assurant Tintegrite et la continuite des 
donnees transmises. Les faibles ressources en memoire d'une plate-forme 
embarquee ne permettent pas non plus de memoriser des flux lineaires done 
des objets de tailie importante au cours de la transmission et des conversions, 

Un des buts de la presente invention est done de proposer un precede 
permettant au programmeur d'une application utilisant une plate-forme 
embarquee de disposer d'outils logiciels automatises permettant ^ un agent 
iogiciel, ou element d'application, memorise ou execute dans un tel objet 
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portable, de recevoir ou d'envoyer a un autre agent, situe sur une autre station 
informatique, des donnees organisees sous la forme d'objets logiciels 
structures, lorsque les moyens de communications entre eux ne permettent pas 
le transfert en tant que telles des structures qui les composent, mais seulement 
le transfert de donnees sous une forme plus simple, et que les ressources 
logicielles et materielles de cette plate-forme embarquee ne sont pas 
suffisantes pour permettre Tutilisation d'un precede classique de serialisation. 

Get objectif est atteint par un precede de conversion de donnees 
utilisable par une station informatique, dite plate-fomne embarquee. comprenant 
un objet portable incluant au moins un processeur. des moyens de 
memorisation, et des moyens de communication aptes a echanger des 
informations avec un terminal sous la forme d'une ou plusieurs successions 
lin6aires de donnees, caracterise en ce qu'il comporte une etape de conversion 
d'un ensemble de donnees, dans un sens ou dans I'autre, entre d'une part un 
15 agencement en une succession lineaire de donnees et d'autre part un 
agencement structure decrivant ou representant un ou plusieurs objets logiciels 
structures ou hierarchises suivant les criteres d'un langage de programmation 
oriente objet. 

Selon une particularite, le proced6 comporte des 6tapes de : 
20 - conversion, ou serialisation, d'un premier ensemble de donn6es a 
transmettre comportant ou representant un ou plusieurs objets logiciels 
structures ou hierarchises suivant les criteres d'un langage de 
programmation oriente objet, depuis un agencement structure decrivant ou 
representant cet objet vers une succession lineaire de donn6es 
25 representant ce premier ensemble de donnees ; 

- transmission de cette succession lineaire de donnees par des moyens de 
communication, depuis la plate-forme embarquee vers au fndins un ti6te, 
c'est a dire un terminal ou une station informatique reliee au terminal, ou de 
cet hote vers la plate-forme embarquee ; 
30 - conversion apres transmission, ou d6-serialisation. de cette succession 
lineaire de donn6es versun ensemble de donnees agence en un ou 
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plusieurs objets logiciels structures reproduisant ou representant le premier 
ensemble de donnees. 

Selon une particularite, le terminal h6te envoie des informations a la 
plate-forme embarquee en utilisant un agent logiciel, dit fonction de 
5 transmission, ces informations etant regues dans la plate-forme embarquee par 
une fonction de reponse apte a declencher un traitement de ces donnees par 
au moins un agent logiciel destfnataire memorise dans la plate-forme 
embarquee et faisant partie d'au moins une application. le precede comprenant 
des etapes de : 

10 - reception, par un agent de communication en lieu et place de I'agent 
destinataire, d'un ensemble de donnees regues par la fonction de reponse d 
r intention de cet agent logiciel destinataire, cet ensemble de donnees etant 
agence en une succession lineaire de donn6es ; 

- conversion de cet ensemble de donnees en au moins un objet logiciel, 
15 structure ou hierarchise suivant les criteres d'un langage de programmatibn 

orients objet ; >, 

- transmission de cet objet logiciel structure a I'agent destinataire :':et 
declenchement d'un traitement en fonction de cet objet par cet agent 
destinataire. 

-0 Selon une particularite, le precede comporte des etapes de : 

- reception par la fonction de reponse, en provenance de la fonction de 
transmission de I'liote, d'au moins une donnee sous forme d'au moins un 
parametre d'envoi, et transmission de ce parametre a un agent de 
communication memorise ou execute dans la plate-forme embarquee ; 

15 - conversion, ou concatenation, par I'agent de communication d'au moins un 
parametre d'envoi, transmis par I'agent de reponse, en un ensemble de 
donnees agence en une succession lineaire de donnees et memorisation de 
ces donnees dans un flux d'entree dans la plate-forme embarquee ; 

- conversion, ou de-serialisation, par un agent de serialisation, memorise ou 
0 execute dans la plate-fonne embarquee, d'au moins une partie des 

donnees memoris§es dans ce flux d'entree vers un ensemble de donnees 
comprenant ou representant au moins un objet logiciel structure ; 
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reception de cet objet logiciel structure ou de ses references par I'agent 
destinataire. 

Selon une particularite, le precede comporte des etapes de : 
transmission d'un objet logiciel structure ou de sa representation depuis un 
agent logiciel faisant partie d'une application executee ou memorisee dans 
une plate-forme embarquee vers un agent de serialisation execute ou 
memorise dans cette plate-forme embarquee ; 

conversion, ou serialisation, par cet agent de serialisation de cet objet 
logiciel structure vers un ensemble de donnees agence en une succession 
lineaire de donn6es et memorisation de ces donnees dans un flux de sortie 
dans la plate-forme embarquee ; 

- conversion par un agent de communication, memorise ou execute dans la 
plate-forme embarquee, d'au moins une partie des donnees memorisees 
dans ce flux de sortie vers un ensemble de parametres de reponse aptes ^ 
etre transmis par la fonction de reponse ; 

- transmission de ces parametres de reponse depuis la plate-forme 
embarquee vers le terminal bote par la fonction de reponse, de sa propre 
initiative ou en reponse a la fonction de transmission du terminal h6te. 

Selon une particularite, la succession lineaire de donnees memorisee 
dans le flux d'entree ou le flux de sortie represente un ou plusieurs objets 
logiciels structures ou hierarchises en utilisant une ou plusieurs donnees, dites 
balises. ayant une ou plusieurs valeurs determinees representant chacune une 
action determinee a effectuer iors de la deserialisation de cette succession 
lineaire de donnees. 

Selon une particularite, au moins une balise est definie comme 
representant une des actions suivantes : 

ajout d'un nouvel element ^ la stmcture de I'objet structure represente par 

la succession lineaire de donnees ; 

- reference a un element ou objet. dit objet source, en tant que source de la 
valeur de tout ou partie d'un element composant I'objet structure ; 

- indication que la ou les donnees suivantes representent le contenu d'un 
element composant I'objet structure ; 
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- indication d'une absence de contenu d'un element composant Tobjet 
structure. 

Selon una particularite, ('agent de s6rialisation effectue la serialisation 
d'un objet structure, dit objet de depart, en un ensemble lineaire de donnees 
suivant un precede, dit precede de serialisation, traitant au moins un des 
objets, dits elements, composant la structure ou Tarborescence de cet objet 
structure de depart, selon des etapes de : 

- detection, par I'agent de serialisation du type d'un element, dit objet en 
cours, composant la structure ou I'arborescence de cet objet structure ; 

- memorisation dans le flux de sortie d'une donnee representant une balise 
indiquant Tajout d'un nouvel element, suivie d'une donnee representant le 
type de T objet en cours ; 

- memorisation dans le flux de sortie, a la suite des elements qui y sont deja 
presents, par un agent de serialisation de type associe au type de Tobj^t 
en cours. 

■ soit d'au moins une donnee representant la valeur de tout ou partle d^; 
Tobjet structure ; 

■ soit d*au moins une donnee representant une balise indiquant une 
reference a un objet en tant que source de la valeur de tout ou partie de 
Tobjet structure, cette balise etant suivie d'une donnee identifiant ledit 
objet source ; 

Selon une particularite, le precede de serialisation effectue la 
conversion d'un objet structure vers le flux de sortie en memorisant au fur et a 
mesure de ses iterations le type de chaque objet en cours dans une pile 
memoire. dite pile de types, dont les emplacements sont lus dans I'ordre 
inverse de leur ordre de memorisation. 

Selon une particularite, Tagent de serialisation effectue la 
deserialisation d'un ensemble lineaire de donnees en au moins un objet 
structure resultat. suivant un precede, dit precede de deserialisation, traitant 
chacune des donnees. memorisees dans (e flux d' entree, selon des etapes de : 
- lecture par I'agent de serialisation d'au moins une donnee memorisee dans 
le flux d'entr^e a la suite des donnees precedemment traitees ; 
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- analyse de cette donnee et realisation d*une action correspondant a cette 
donnee. 

Un des buts de !' invention est egalement de proposer un te! procede de 
5 transfert d'objets structure permettant le transfert d'objets logiciels entre un 
hSte et une plate-forme embarquee lorsque Tenvironnement de fonctionnement 
de cette plate-forme embarquee ne comporte pas d' agent gestionnaire de 
types pour de tels objets structures. 

Ce but est atteint par le procede de conversion de donnees decrit ci- 
10 dessus, caracterise en ce que le procede de deserialisation comprend le 
' remplissage d'un element, dit objet en cours, c'est a dire I'affectation d'une 
valeur directe ou indirecte a tout ou partie de cet objet en cours, cet element 
composant tout ou partie de la structure de Tobjet structure resultat, la fin du 
remplissage de T objet en cours declenchant 
15 - la lecture d*une donnee representant un type d'objet memorise dans le 
prochain emplacement d'une structure de memoire, dite pile de types, et 
reffacement de cette donnee de cet emplacement ; 

- la memorisation, comme type d'un nouvel objet en cours. du type 
represents par la donnee lue dans la pile de types. 

20 Selon une particularite, I' objet structure cree par le procede de 

deserialisation est considere comme complet et transmis a T agent logiciel ou 
Tapplication qui en est destinataire lorsque la pile de types est vide. 

Selon une particularite, Taction de deserialisation correspondant a une 
donnee representant une balise, dite balise « NEW », indiquant un nouvel 

25 element comprend des etapes de : 

- lecture d'au moins une donnee suivante dans le flux d'entree ; 

- memorisation du type d'objet, represente par cette meme donnee suivante, 
dans une pile memoire, dite pile de types, a la suite des types qui y sont 
deja eventuellement memorises ; 

30 Selon une particularite, la pile de types utilisee par le procede de 

deserialisation comprend une pile de type LIFO, c'est a dire dont les 
emplacements sont lus dans I'ordre inverse de leur ordre de memorisation. 
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Selon une particularite, le procede de deserialisation cxjmprend une 
6tape de creation d'un element composant la structure de I'objet logiclel 
structure resultat, par allocation d'un nouvel espace memoire ou par 
reutillsation d'une allocation libre, cette creation etant realis^e par un agent de 
controle de type correspondant au type de I'element a creer. 

Selon une particularite, I'etape de creation d'un element composant la 
structure de I'objet logiciel structure resultat a lieu entre I'etape de lecture d'une 
donnee Indlquant la creation de cet element et la premiere etape de 
remplissage de ce meme element. 

Selon une particularite, I'action correspondant a une donnee, dite 
donnee simple, c'est a dire ne representant pas une balise, comprend une 
etape de memorisation de la valeur de cette donnee dans Tespace memoire 
alloue d I'objet en cours. 

Selon une particularite. au cours du procede de deserialisation, un 
index d'objet est attribue a au moins un element composant la structure de 
I'objet structure resultat, cet index d'objet identifiant cet element de fagon 
unique et lui permettant d'etre designe ou reference par d'autres objets ou 
elements. 

Selon une particularite. I'action correspondant a une donnee 
representant une balise, dIte balise « REF », indiquant une reference comprend 
des etapes de : 

- lecture d'au moins une donn6e suivante dans le flux d'entree ; 

- memorisation dans I'espace memoire alloue a I'objet en cours. a la suite 
des donnees d6jii memorisees, d'une donnee designant un objet comme 
source de la valeur de tout ou parlie de I'objet en cours, cet objet ou 
element source etant rdentifie par ladite donnee suivante. 

Selon une particularite, le remplissage de I'objet en cours est considere 
comme termine lorsque les donnees memorisees dans I'espace memoire qui 
lui est alloue correspondent a une longueur determinee, cette longueur etant 
lue en memoire dans la carte par un agent de controle de type ou par un agent 
gestionnaire de types memorise dans la plate-forme embarquee. 
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Selon une particularite. renvoi par la plate-forme embarqu6e, vers 
I'hote. d-une succession lin6aire de donnees d'une longueur d6termin6e. 
s'effectue selon un precede iteratif. dit de lecture de donnees. comprenant des 

stapes recursives de : 
5 - envoi par ThSte d'une commande de communication aveo passage d'au 
moins un parametre d'envol representant la longueur des donnees d6j^ 
regues ; 

- reception par la plate-forme embarquee du param§tre d'envoi et 
comparaison avec la succession lineaire de donnees S transmettre ; 

10 - reponse a la commande de communication par I'envoi d'au moins un 
parametre de retour representant la ou les donnees suivant imm^diatement 
les donnees d6ja re?ues par I'hote ; 

- reception par I'hote du parametre de retour de la commande de 
communication et memorisation des donnees qu'il represente a la suite des 

15 donnees deja re?ues. 

Selon une particularite, la reception par la plate-forme embarquee, en 
provenance de I'h6te, d'une succession lineaire de donnees d'une longueur 
determinee. s'effectue selon un proced§ iteratif. dit d'^criture de donnees. 
comprenant des etapes recursives de : 
20 - envoi par I'hSte d'une commande de communication avec passage d'au 
moins un premier parametre d'envoi repr6sentant la ou les donnees suivant 
Immediatement la partie deja transmise de la succession lineaire de 
donnees a transmettre, ainsi eventuellement qu'un deuxidme parametre 
d'envoi representant la position, dans la succession ^ transmettre. des 
25 donn6es representees par le premier parametre d'envoi ou la longueur des 
donnees deja transmises ; 
_ reception par la plate-forme embarquee du ou des paramfetres d'envoi. de la 

commande de communication ; 
- memorisation dans un flux d'entr^e dans la plate-forme embarqu6e des 
30 donn6es representees par le premier parametre d'envoi a la suite des 
donnees deja regues. 
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Selon une particularite, le procede d'ecriture de donnees comprend en 
outre les stapes suivantes : 

- comparaison par la plate-forme embarquee du deuxi^me parametre d'envoi 
et comparaison avec la longueur des donnees deja re$ues ; 

- retour par la plate-forme embarquee d'au moins un parametre de reponse 
representant solt la longueur des donnees deja re?ues soft une donnee 
representant le resultatde cette comparaison solt les deux ; 

Un des buts de invention est egalement de proposer un tel procede de 
transfert d'objets structure permettant le transfert d'objets loglciels d'une taille 
importante par rapport aux possibilites des moyens de communication en 
mati6re de transfert ou de stockage provisoire. ou d'objets logiciels de taille 
illlmit^e. 

Ce but est atteint par le procede de conversion de donn§es decrit 6i- 
dessus. caracteris6 en ce qu'au moins deux des precedes de serialisation, 
deserialisation, lecture de donn6es, ou ecriture de donnees sont effectues kn 
parallele ou de fa9on entrelac6e par repetition d'une etape comprenant 
['execution successive d'au moins une §tape de chacun de ces precedes. 

Selon une particularity, le flux d'entr^e ou le flux de sortie ou les deux 
20 sont memorises sous la forme de structures circulaires de memoire, ces deux 
flux pouvant partager la m§me structure circulaire. 

Selon une particularity, la plate-fomne embarquee comporte un 
environnement programmable apte d memoriser et executer au moins une 
application r§all86e par un programmeur. la fonction de communication etant 
25 compatible avec le format « APDU » d§1ini dans la norme ISO 78 1 6. 

Selon une particularity, des operations de deserialisation puis 
traitement d'un objet regu sont declenchees par la reception d'au moins une 
commande au format APDU comprenant au moins une donnee indiquant la 
reception d'un objet structure. 

Selon une particularite. la plate-fomrie embarquee comporte un 
environnement programmable compatible avec le standard JavaCard (marque 
deposee). 
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Selon une particularlte, au moins une des applications ex6cut6es sur 
I'hdte ou la plate-forme embarquee est programmee en langage Java®. 

Selon une particularite, le proced6 est utilise pour la communication 
entre au moins un agent logiciel, dit agent de carte, memorise ou ex6cut6 dans 
la plate-forme embarquee et au moins un agent logiciel. dit agent proxy de 
moteur de carte memorise ou execute dans au moins un hote appartenant a un 
reseau informatique communiquant par messages asynchrones selon une 
infrastructure logicielle de type AAA-WIOM. cet agent proxy de moteur de carte 
servant d'intermediaire a 1' agent de carte dans ses communications avec 
d'autres agents de ce reseau, ces agents fonctionnant selon les specifications 
de cette infrastructure logicielle et appartenant a au moins une application 
distribuee. 

Par ailleurs, dans certains environnements ou systemes d'exploitation, 
par exemple de type embarqu6 comme JavaCard®. il n'existe pas de 
procedure, ou seulement des procedures complexes et couteuses en temnes 
de ressources. pour supprimer un tel objet logiciel une fois qu'il n'est plus 
utilise ou liberer I'espace qu'il occupe dans les moyens de memorisation. Cette 
suppression doit alors Stre faite « manuellement ». c'est & dire §tre pr6vue 
directement et au cas par cas par le programmeur de I' application. 

Un des buts de la pr§sente invention est done de proposer un precede 
pemiettant au programmeur d'une application utilisant une plate-fomie 
embarquee de disposer d'outils logiciels permettant la reutilisation de I'espace 
memoire occupe par tout ou partie de certains objets logiciels structures utilises 
par une application dans une station de traitement de donnees portable ou non. 

II peut egalement etre utile de disposer d'outils logiciel permettant de 
realiser ais6ment la duplication d'un-objet logiciel comportant une structure non 
lineaire. par exemple sous fomie d'arborescence. 

Un des buts de la presente invention est done de proposer un precede 
permettant au programmeur d'une application utilisant une plate-fonme 
embarquee de disposer d'outils logiciels permettant la duplication d'un objet 
logiciel structure, dit de depart, vers un autre objet. dit resultat. contenant les 
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memes valeurs que Tobjet de depart mais constituant un objet different en 
memoirs. 

De m§me, pour des raisons de securite, lorsque Tespace occupe par 
un tei objet logiciel se libere, il peut etre important d'effacer de cet espace les 
5 informations provenant de cet objet, pour eviter que ces informations puissent 
§tre lues par un autre objet ou une autre application rdutilisant ce mSme 
espace plus tard. Cet effacement doit alors §tre fait « manuellement », c*est a 
dire 6tre prevu directement et au cas par cas par le programmeur de 
r application. 

10 Un des buts de la pr6sente invention est done de proposer un proced6 

permettant au programmeur d*une application utilisant une plate-forme 
embarquee de disposer d'outils logiciels permettant I'effacement ou 
I'uniformisation des informations contenues dans Tespace m§moire utilise par 
un tel objet logiciel lors de la suppression de celui-ci ou de la reutilisation de cet 

15 espace. 

L'invention propose alors un precede comme decrit plus haut, 
caracterise en ce que les precedes de lecture de donnees, d'ecriture de 
donnees, de de-serialisation ou de serialisation sont mis en oeuvre a travers 
leur implementation dans au moins une classe memorisee dans I'hdte ou dans 
20 ia plate-forme embarquee, cette implementation comprenant au moins Tune 
des commandes suivantes : 

- une commande d'ecriture d'objet, effectuant la transmission d'un objet 
structure a au moins un agent de la plate-forme embarqu§e, par utilisation 
du precede de s6rialisation de cet objet, puis du proced§ d'ecriture de 

25 donnees, puis du precede de de-s6rialisation ; 

- une commande de lecture d'objet, effectuant la lecture d'un objet structure 
depuis au moins un agent de la plate-forme embarquee. par utilisation du 
procSde de serialisation puis du proced6 de lecture de donnees, puis du 
precede de deserialisation ; 

30 - une commande de desallocation d'un objet structure memorise dans la 
plate-forme embarquee, par utilisation du proc6de de serialisation, celui-ci 
comprenant en outre une etape de memorisation de la liberation ou 
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desallocation de Tespace memoire allou6 a chaque composant de cet objet, 
apres analyse de la structure de ce composant ; 

- une commande de nettoyage ou effacement d'un espace memoire Iiber6 
par un objet structure, par utilisation du procSde de deserialisation pour 

5 creer un objet de contenu sans signification a partir d'une succession 
lineaire de donnees determinee ; 

- une commande de duplication d'un objet structure dit de depart, par 
utilisation du proc6de de serialisation, sans desallocation de cet objet de 
depart, pour creer une succession lineaire de donnees reprdsentant ce 

10 meme objet, puis par utilisation du precede de deserialisation a partir de 
cette succession lineaire de donnees pour creer un autre objet structure de 
contenu identique ^ Tobjet de depart. 

Selon une particularite, le langage de programmation de la plate-forme 
embarquee comporte une premiere classe (lOApplet) decrivant une m6thode 
15 abstraite ProcessAPDU Ian9ant, lors de la reception d'un message APDU, un 
traitement parametrable dans I' application ; le code programme realisant les 
operations de deserialisation dans la plate-forme embarquee etant memorise 
dans la plate-forme embarquee, en tant qu' implementation de cette metliode 
abstraite ProcessAPDU, dans une deuxieme classe (ObjectlOApplet) h6ritant 
20 de la premifere classe (lOApplet), ce meme code programme faisant appel a 
une methode ProcessObject elle-meme decrfte comme une methode abstraite 
dans cette mSme classe (ObjectlOApplet) d' implementation. 

Selon une particularite. le langage de programmation de la plate-forme 
embarquee comporte une premiere classe (lOApplet) d6crivant une methode 
25 SendAPDU emettant vers I'hdte un message au format APDU ; le code 
programme realisant les operations de serialisation dans la plate-forme 
" embarquee etant memorise, en tant quMmpjerrientation d'au moins une 
methode SendObject faisant appel a la methode SendAPDU, dans une 
deuxieme classe (ObjectlOApplet) de carte heritant de la classe (lOApplet). 

30 

Un autre but de r invention est de proposer un systeme informatique 
incluant un tel objet portable et comportant de tels outils logiciels. 
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Get objectif est attaint par un systeme informatique comprenant une 
station informatique, dite plate-forme embarquee, comprenant un objet portable 
incluant au moins un processeur, des moyens de memorisation, et des moyens 
de communication aptes a echanger des informations avec un terminal sous la 
forme d'une ou plusieurs successions lineaires de donnees, caracterise en ce 
que la plate-forme comprend un agent de serialisation apte a effectuer une 
etape de conversion d'un ensemble de donn6es, dans un sens ou dans Tautre, 
entre d'une part un agencement en une succession lineaire de donnees et 
d'autre part un agencement structure decrivant ou representant un ou plusieurs 
objets logiciels structures ou hierarchises suivant les criteres d'un langage de 
programmation oriente objet. 

Selon une particularite, la plate-forme embarquee comprend un agent 
de communication apte a : 

- recevoir en lieu et place de Pagent destinataire un ensemble de donneds 
re9ues par la fonction de reponse a T intention d'un agent logicifel 
destinataire memorise dans la plate-forme embarquee, cet ensemble de 
donnees etant agence en une ou plusieurs successions lineaires de 
donnees ; 

- convertir cet ensemble de donnees en au moins un objet logiciel, structure 
ou hierarchfs§ suivant les criteres d'un langage de programmation oriente 
objet ; 

- transmettre cet objet logiciel structure a Pagent destinataire et declencher 
un traitement en fonction de cet objet par cet agent destinataire. 

Selon une particularity, la succession lineaire de donnees representant 
un objet logiciel structure est memorisee dans la plate-forme embarquee dans 
un flux d'entree ou un flux de sortie, la plate-forme embarquee comportant un 
agent logiciel dit agent de serialisation apte a creer dans la plate-forme 
embarquee le ou les objets structures representes par le flux d'entree. c'est a 
dire a des6rialiser ces objets structures, ou d §crire dans le flux de sortie des 
donnees representant le ou les objets structures a transmettre, c'est a dire a 
s6rialiser ces objets structures. 
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Selon une particularite. le flux d'entree ou le flux de sortie sont 
memorises sous la forme d'une ou plusieurs structures circulalres de memoire. 

Selon une particularite, I' agent de serialisation utilise une pile m6moire, 
dite pile de types, pour memoriser le type d'au moins un objet composant tout 
5 ou partie de la structure d'un objet structure a serialiser ou d6s6rialiser, cette 
pile de type comportant des emplacements memoires qui ne sont chacun 
accessible qu'apres que les emplacements memorises plus recemment aient 
et6 lus et effaces. 

Selon une particularite, les donn6es contenues dans les flux d'entree 
10 ou de sortie representent un ou plusieurs objets structures en utilisant un 
codage comprenant un jeu de balises, ces balises repr^sentant chacune une 
action determinee a effectuer lots de la deserialisation de cette succession 
lineaire de donn^es. 

Selon une particularite, au moins une balise est definie comme 
15 representant une des actions suivantes : 

- ajout d'un nouvel element a la structure de I'objet structure represente par 
la succession lineaire de donn6es ; 

- reference a un element ou objet, dit objet source, en tant que source de la 
valeur de tout ou partie d'un element composant I'objet structure ; 

20 - indication que la ou les donn6es suivantes representent le contenu d'un 
element composant I'objet structure ; 

- indication d'une absence de contenu d'un element composant I'objet 
structure. 

Selon une particularite. la plate-fomie embarquee comprend un objet 
25 portable fonctionnant selon la norme IS07816 et utilisant des commandes au 
format APDU. 

Selon une particularite, au moins un- agent ou application memorise 

dans la plate-forme embarquee est programme en langage Java®, la plate- 
forme embarquee comportant un environnement informatique selon le standard 

30 JavaCard®. 
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Selon une particularite, le systeme comports dans I'hote ou dans la 
plate-forme embarquee, ou les deux, au moins une classe logicielle 
implementant au moins Tune des commandes suivantes : 

- une commande d'ecriture d'objet, effectuant la transmission d'un objet 
structure a au moins un agent de ia carte, par serialisation de cet objet 
structure en un flux de donnees dans Thdte, puis envoi de ce flux de 
donn^es dans la plate-forme embarquee, puis de-serialisation de ce flux de 
donnees en un objet structure dans la plate-forme embarquee ; 

- une commande de lecture d^objet, effectuant la lecture d'un objet structure 
depuis au moins un agent de la carte, par serialisation de cet objet structure 
en un flux de donnees dans la plate-forme embarquee, puis reception 
depuis la plate-forme embarquee de ce flux de donnees, puis 
deserialisation de ce flux de donnSes en un objet structure dans I'hote ; 

- une commande de desallocation d'un objet structure memorise dans la 
plate-forme embarquee, par une serialisation de cet objet selon une option 
comprenant une liberation ou desallocation de I'espace memoire alloue^a 
chaque composant^de cet objet, apr§s analyse de la structure de ce 
composant ; 

- une commande de nettoyage ou effacement d'un espace memoire libere 
par un objet stmcture dans la plate-forme embarquee, par deserialisation 
d'une succession lineaire de donnees determinee pour creer un objet de 
contenu sans signification ; 

- une commande de duplication dans la plate-forme embarquee d'un objet 
structure dit de depart, par serialisation en une succession lineaire de 
donnees representant ce meme objet. sans desallocation de cet objet de 
depart, puis par deserialisation d partir de cette succession lineaire de 
donnees en un autre objet structure de contenu identique a T objet de 
depart. 

Selon une particularite, la plate-forme embarqu6e communique au 
moins un hote appartenant a un reseau infonnatique communiquant par 
messages asynchrones selon une infrastructure logicielle de type AAA-MOM, 
cet hote comprenant un agent logiciel, dit agent proxy de moteur de carte, apte 
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a gerer les communications de cette plate-forme embarqu6e avec d'autres 
agents de ce reseau, ces agents fonctionnant selon les specifications de cette 
infrastructure logicielle et appartenant a au moins une application distribuee. 



L' invention, avec ses caracteristiques et avantages, ressortira plus 
clairement a la lecture de la description falte en reference aux dessins annexes 
dans lesquels : 

la figure 1 represents un schema symbolique partiel des 
transferts d'objets et de leurs conversions lors d'operations 
d'ecriture et de lecture d'un hdte ou terminal vers et depuis 
un agent logiciel d'une plate-forme embarqu6e. dans un 
mode de realisation de ^invention oCi la carte ne comporte 
qu*une seule application ; 

ia figure 2 represente un schema symbolique plus detaille 
des transferts d'objets et de leurs conversions lors 
d'operations d'6criture et de lecture d'un hdte ou tenninal 
vers et depuis un agent logiciel d'une plate-forme 
embarquee, dans un mode de realisation de Tinvention ou la 
carte ne comporte qu'une seule application ; 
la figure 3 represente un schema symbolique partiel des 
transferts d'objets et de leurs conversions lors d' operations 
d' Venture et de lecture d'un hote ou terminal vers et depuis 
un agent logiciel d'une plate-forme embarquee, dans un 
mode de r6alisation de 1' invention oCj la carte comporte 
piusieurs applications ; 

- -la figure 4 represente un schema symbolique partiel des 

objets et agents mis en oeuvre lors de la deserialisation d'un 
objet logiciel structure, d partir d'un flux de donnees ; 
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la figure 5 represente un schema symbolique partiel des 
objets et agents mis en oeuvre lors de la serialisation d'un 
objet logiciel structure, vers un flux de donnees. 

5 

Dans certains ouvrages (par exemple « Java embarque » - Eyrolles - 
Paris 1999), le terme d'ordinateur « embarque » est utilise pour designer un 
ordinateur qui n*est pas visible en tant que tel mais integre dans un equipement 
dote d'une autre fonction. Ce terme serait une traduction approximative de 
10 I'anglals « embedded computer », qui signifie litteralement « ordinateur enfoui » 
ou « enchasse ». 

Cette caract6ristique. de remplir une fonction particuli§re au sein d'un 
autre dispositif, explique grandement le fait que de tels ordinateurs embarqu6s 
disposent souvent de ressources mat6rielles ou logicielles limitees, et utilisent 

15 souvent un systeme d'exploitation ou un environnement logiciel rudimentairei 
Bien que des evolutions soient previsibles, les ressources de tels ordinateurs 
peuvent typlquement dtre de I'ordre de 512 kilo-octets de m6moire statique ^ 
quelques kilo-octets, pour un processeur de 8 ou 16 bits. Dans le cas d'une 
carte a puce, la m6molre vive (RAM) disponible peut etre d*environ 4 kilo- 

20 octets, et aller actuellement jusqu'^ 32 kilo-octets pour les modeles les plus 
performants. 

De fa9on generate en informatique, le terme de plate-fonne designe un 
dispositif de traitement de donnees comprenant au moins un processeur et des 
moyens de memorisation. Par extension a la definition ci-dessus, et pour la 
25 presente description, le terme de « plate-fonne embarqu6e » sera utilise pour 
designer un objet portable incluant une telle plate-forme, cet objet etant 
portable ou de faible taille, ou ayant de faibles capacites de traitement ou de 
mdmorisation. 

30 La presente description expose le proc6de selon invention dans des 

modes de realisation comportant une repartition d6terminee des taches et 
operations entre les dffferents agents et applications concernes. La flexibilite de 
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Torganisation d'une application informatique permet bien sur de presenter 
differemment cette repartition, en particulier lorsque les distinctions entre las 
differents agents et leurs denonninatlons sont des notions abstraites n'influant 
pas sur leurs caracteristiques principales de fonctionnement, 11 est done evident 
5 que le precede selon T invention peut egalement etre nais en oeuvre dans 
d*autres modes de realisation non decrits ici, sans sortir de Tesprlt de 
rinvention, en particulier en combinant differemment les diverses variantes 
exposees pour chaque tache ou agent. De meme, la repartition abstraite des 
taches entre des agents ou applications memorises en un meme lieu et temps, 
10 peut etre combinee en diverses variantes non decrites ici sans sortir de Tesprlt 
de rinvention. 

Dans la presente description, le proced§ selon rinvention sera illustre 
principalement dans le cas d'une plate-forme embarqu6e comprenant une 

15 carte a puce (souvent appelee «smartcard» en anglais) utilisant un 
environnement systems de type JavaCard®, communiquant avec un terminal 
comprenant une station de traitement de donnees executant une application 
programmee en langage Java®. 

II doit toutefois etre evident que le precede selon rinvention peut etre 

20 applique a d'autres envfronnements dont les fonctions de transmission de 
donn6es ne permettent pas de transmettre des objets logiciels structures de 
fagon transparente pour le programmeur. II peut ainsi s'agir de cartes a puce 
selon la nonne ISO 7816 utilisant un autre environnement de programmation, 
par exemple « Windows for Smart Cards® », ou programmable avec un autre 

25 langage de programmation, par exemple Visual Basic®. II peut §galement 
s'agir de cartes a puce selon une autre norme comportant des limites similaires 

- — dans leurs fonctions de communication, ou d'objets ou terminaux portables 
utilisant une telle plate-forme 

De meme, il peut aussi bien s'agir d'objets portables quelconques 

30 comprenant une station de traitement de donnees embarquee, amovible ou 
non, comme par exemple un composant §lectronlque automobile, un marqueur 
de rep§rage, un telephone cellulaire, ou un terminal de saisie portable. 
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De meme, le precede selon I'invention sera lllustre principalement 
comme applique a Tutilisation d'une plate-forme embarquee communiquant 
avec une station de traitement de donnee, dite terminal ou hote. Ce procede 
5 peut bien sQr egalement etre utilise dans le cas ou le terminal est une station 
faisant partie d'un reseau informatique de quelque type que ce soit, sans sortir 
de Tesprit de ('invention. Ainsi. les diff§rentes fonctions presentees comme 
r6alisees par ce terminal peuvent aussi bien dtre r^parties sur plusieurs 
dispositifs differents, voire selon une repartition variant dans le temps. Bien sur, 

10 le procede d6crit peut egalement etre applique au cas ou la plate-forme 
embarquee communique directement ou indirectement avec une ou plusieurs 
autres plates-formes embarqu6es, sans sortir non plus de I'esprit de T invention. 
De fa?on generate, rh6te ou le terminal hdte sera done d6fini comme 
I'application ou la station communiquant avec la plate-forme embarqu6e. s 

15 ^ 
Le proc6d6 selon I'invention peut en particulier etre applique a is 
communication d'une carte a puce, par exemple au standard JavaCard®, avec 
un r6seau informatique, par exemple programme en Java®, communiquant par 
messages asynchrones selon une infrastructure logidelle de type AAA-MOM. 

20 Dans ce cas, les communications de la carte avec le reste du r6seau sont 
typiquement g6r6es par un agent logiciel, dit agent proxy d'agent de carte, qui 
sert d'intermediaire pour chacun des agents logiciels, dits agents de carte, 
memorises dans la carte. Dans renvironnement de la carte, ces agents de 
cartes sont g§res ou animes, ou les deux, par un agent logiciel dit agent moteur 

25 de carte. 

Le procede selon invention permet alors a cet agent moteur de carte 
de communiquer avec T agent proxy de moteur de carte en s'echangeant des 
objets logiciels structures selon les normes du langage Java ou de 
r infrastructure AAA. Le fait de pouvoir echanger des objets structures avec 
30 Texterieur permet ainsi ^ la carte d'§tre miieux compatible avec T infrastructure 
AAA, et d'Stre vue elle-meme comme un agent de type AAA par le reste des 
agents AAA de ce reseau. 
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Le precede selon T invention peut egalennent etre applique a la 
communication d'une carte a puce, par exemple au standard JavaCard®, avec 
un reseau informatique, par exemple programme en Java®, communiquant 
5 utilisant un protocole RPC (« Remote Procedure Call ») oriente objet, par 
exemple selon une infrastructure logicielle de type Java RMl (« Remote Method 
Invocation ») ou CORBA (marque deposee). 

Lorsqu'une application n6cessite de transferer des objets logiciels 
10 depuis un terminal vers une plate-forme embarquee constituee d'une carte a 
puce, ce transfer! s^effectue souvent sous la forme d'une communication de 
type maitre/esclave. C*est a dire que c'est le terminal qui prend {'initiative 
d'executer une fonction de transmission vers la plate-forme embarquee. Pour 
communiquer, cette fonction envoie a cette plate-forme une commande de 
15 communication assortie de parametres d'envoi. Cette commande est alors 
capable de declencher un ou plusieurs traitements au sein de la plate-forme, et 
de recevoir en retour des parametres de retour ou de reponse. 

Dans le cas d'une carte a puce fonctionnant selon la norma ISO 7816. 
les parametres de cette commande sont transmis sulvant un fomiat de type 
20 APDU (« Application Protocol Data Unit »), qui consiste en une succession de 
donnees organisees comme suit : 



Parametres d' envoi transmis avec la commande : 



en-tete 


corps 


CLA 


INS 


P1 


P2 


Lc 


DataT 


Le 



CLA : un octet designant la classe ou T application destinataire 



25 INS : un octet designant une instruction a ex6cuter - — 

P1 , P2 : deux octets apportant des precisions sur la commande APDU 
Lc : longueur des donnees envoySes 
Data : donnees envoyees 
Le : longueur des donnees attendues en retour 
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Parametres de reponse retournes par la carte : 



corps 


fin 


Data R 


SW1 


SW2 



Data : donnees repondues 



5 SW1, SW2 : deux octets constituant des messages ou codes de controle 
renvoyes par la carte 

On voit que ce format APDU ne permet d'envoyer ou de recevoir de 

10 donnees que sous forme d'une succession lineaire de donnees, c'est a dire 
une simple suite d'octets. Lorsqu'une application est programmee dans un 
langage ou pour une plate-forme embarquee dont ie systeme ne dispose que 
des commandes APDU pour communiquer, Ie programmeur qui veut transferer 
des objets plus structures ne dispose done pas d'outils logiciels simples. II e^t 

15 oblige de prevoir dans son application de convertir de tels objets structures eh 
une suite d'octets, puis d'utiliser la commande APDU pour les transmettre, puis 
de reconvertir ces objets dans Ie sens inverse. II s'agit la de r6aliser 
« manuellement », c'est a dire de programmer dans les moindres details, la 
serialisation, transmission, puis deserialisation de ces objets. 

20 Dans Ie cas d'un programmeur utilisant Ie langage Java® pour 

developper une application utilisant des plates-formes embarqu6es au standard 
JavaCard®, les outils disponibles dans JavaCard® consistent en une 
transmission de donnees lineaires au format APDU, avec les commandes 
JavaCard® suivantes : 

25 - « process(APDU) » : la carte refoit des donnees au format APDU et 
lance Ie traitement des parametres d'envoi qu'elles contiennent, par 
Tagent loglciel, ou « applet », destinataire designe dans ces donnees ; 
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« sendAPDUQ » ou « APDU.sendbytesQ » : apres ou au cours du 
traitement declenche precedemment, la carte retourne vers I'hote 
d'autres donnees au format APDU, contenant les parametres de retour. 



5 La commande « sendAPDUQ » est implementee au sein de 

Tenvironnement JavaCard dans la classe « lOApplet », sous la forme d'une 
methode applicable a un objet non type contenant des donnees brutes. 

La commande « Process(APDU) », par contre, est declaree au sein de 
Tenvironnement JavaCard dans la classe « lOApplet », sous la forme d'une 

10 methode abstraite. C'est a dire que la methode existe dans I'environnement 
Javacard, mais que le code realisant son fonctionnement doit etre ecrit par le 
programmeur d'une application voulant utiliser cette commande. Le 
programmeur va par exemple creer dans son application une sous-classe 
h^ritant de la classe « lOApplet », cette sous-classe contenant alors une 

15 methode recevant le code du traitement a ex6cuter par cette methode 
« Process(APDU) ». Uenvironnement JavaCard se contente d'appeler la 
m6thode « Process(APDU) » lors de la reception d'un message, et done de 
lancer le traitement que le programmeur a pr6vu dans son code ajoute. 

20 De fagon k fournir a un tei programmeur des outils lul permettant de 

transmettre directement des objets logiciels structures, le precede selon 
rinvention fournit des commandes similaires mais acceptant directement des 
objets logiciels structures, selon les spScificitSs orientees objet du langage 
Java®. Ces commandes sent alors utilisables dans Tenvironnement JavaCard® 

25 et peuvent dtre par exemple du type : « process(Object) » et « sendObject() ». 

Pour permettre au programmeur, egalement ici designe comme 
utilisateur, d' utiliser ces commandes directement sans se preoccuper de la 
syntaxe des commandes APDU, c'est le proced6 selon rinvention qui va 
prendre en charge les operations de serialisation, transmission, et 

30 deserialisation des objets et donnees, entre T application ou agent emetteur et 
Tagent destinataire. 
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Dans le cas d'un environnement JavaCard, ces operations peuvent 
alors etre realisees par Texecution d'un code programme contenu dans la 
methode « Process(APDU) » appartenant a une sous-classe de la classe 
« lOApplet », par example nommee « ObjectlOApplet ». Ce code est done 
5 . automatiquement lance par I'environnement lors de la reception d*un message 
APDU, et contient lui-meme les operations de conversions ainsi que Tappel 
d'une autre methode abstraite « Process(Object) ». Grace a un tel mode de 
realisation de Tinvention, le programmeur n'a plus qu'a ecrire le code des 
traitements qu'il veut voir realises par la carte lors de la reception d'un objet 
10 structure, li va alors ecrire ce code dans une sous-classe heritant de la classe 
« ObjectlOApplet », en tant qu' implementation de la methode abstraite 
« Process(Object) ». 

Dans la presente description, seules les operations de conversion, 
15 serialisation ou deserialisation, effectuees du cote de la carte seront decrites..\II 
est bien sur evident que le proced6 d§crit peut etre utilise aussi bien pogr 
realiser les m§mes operations du cOte de Phote. Les ressources materielles 6t 
logicielles du terminal bote etant (e plus souvent bien superleures ^ celies 
dfsponibles sur la carte, ces operations pourront toutefois egalement etre 
20 programmees ou organisees de fa^on differente du c6te de Thote. sans sortir 
de Tesprit de I'invention. 

Dans un mode de realisation represents en figure 1, un terminal 
h6te (1) communique avec une plate-forme embarquee, par exemple une carte 

25 d puce (2) au standard Javacard®. L'h6te(1) execute au moins une 
application (11) comprenant au moins un agent logicrel (111), et communique 
avec la carte (2) par une fonction de communication (101) au format APDU 
mettant en oeuvre des moyens de communication comportant par exemple un 
emplacement de connexion (100). Get emplacement de connexion comporte 

30 des moyens de connexion, par exemple par contact electrique, par liaison 
hertzienne, par liaison infrarouge, par piste magnetique, ou une combinaison 
de plusieurs de ces types. 
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La carte (2) execute une application (22) comprenant au moins un 
agent logiciel (221), et communique avec I'hote (1) en utilisant une fonction de 
reponse(201) faisant partie de I'environnement systeme JavaCard®. Cette 
fonction de reponse (201) utilise pour cela des moyens de 
5 communication (200) d'un type compatible avec les moyens de 
communication (100) du terminal hote (1). 

Lorsque ragent(111) de l^application (11) hote veut envoyer des 
donnees a I' agent (221) de la carte, ou lui faire executer un traitement (2210), 
ou lui demander des informations qu'elle a en memoire, il execute une 

10 instruction d'ecriture d'objet lanQant le precede dans le sens de I'envoi vers la 
carte d'un objet logiciel structure (31) , cette instruction 6tant par exemple 
denommee « WriteObjectQ ». Get objet logiciel (31) est alors serialise, c'est a 
dire converti en un ensemble de donnees au fonnat APDU, par un agent h6te 
de conversion (12). Get agent hdte de conversion utilise alors la fonction de 

15 communication (101) pour transmettre ces donnees la carte (2) a travers 
Temptacement de connexion (100) de I'hdte et les moyens de 
communication (200) de la carte. 

Une fois re?ues dans la carte par la fonction de reponse (201) g§rant 
les moyens de communication (200), cette fonction de reponse transmet ces 

20 donnees a un agent de conversion de carte (21). Get agent de conversion de 
carte (21) deserialise ces donnees. c'est a dire les convertit dans le sens 
inverse de fagon leur redonner leur structure d'origine, sous la forme d'un 
objet logiciel (34). Get objet logiciel stmcture (34) est alors transmis a 
I'agent (22) destinataire grSce d une instruction de traitement d'objet qui va 

25 effectuer le traitement (2210) correspondant aux donnees regues. cette 
instruction 6tant par exemple denommee « Process(Object) ». 

Lorsque Tagent (221) "de rapplicatlon (22) de la carte (2) veut envoyer 

des donnees ^ ¥ agent (11 1) de Thote (1), ou des informations sur un traitement 
effectue, il execute une instruction d' envoi d' objet langant le precede dans le 

30 sens de renvoi vers Thote d'un objet logiciel stnjctur6 (41) , cette instruction 
etant par exemple denommSe « SendObject() ». Get objet logiciel (41) est alors 
serialise, c'est a dire convertit en un ensemble de donnees au format APDU, 
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par exemple par Tagent de conversion de carte (21). Get agent de conversion 
de carte utilise alors la fonction de reponse (201) pour renvoyer ces donnees a 
la carte (2) a travers ies moyens de communication (200) de la carte et 
r emplacement de connexion (100) de i'hdte. 
5 Une fois revues dans Thote par la fonction de communication (101) 

gerant ['emplacement de connexion (100), cette fonction de communication 
transmet ces donnees a i*agent hote de conversion (12). Get agent hote de 
conversion (12) deserialise ces donnees, c'est a dire Ies convert! dans le sens 
inverse de fagon a leur redonner leur structure d'origine, sous la forme d'un 
10 objet logicie! (44). Get objet loglciel structure (44) est alors transmis ^ 
ragent(ll) destinataire par une instruction de lecture d'objet qui va lire Ies 
donnees regues, cette instruction etant par exemple denommee 
« ReadObjectO ». 

15 La figure 2 represente un mode de realisation de Tinvention oCi Ies 

operations de sSrialisatton/dSserialisation et transmission realisees par l^s 
agents (12, 21) de conversion respectivement d'hSte et de carte sont 
effectu6es par deux agents diff6rents (121 , 122, respectivement 21 1. 212). 

Uagent (21) de conversion de carte comprend ainsi un agent (211) de 

20 communication et un agent (212) de serialisation. L'agent(211) de 
communication g6re Ies operations de conversion au niveau de Toctet, en 
6changeant des donnees sous forme de parametres d'envoi (32) et de 
reponse (43) avec la fonction (201) de reponse. En reception de donnees. cet 
agent (211) de communication v§rifie que Ies donnees regues sont completes, 

25 et effectue une concatenation des parametres d' envoi (32) en une succession 
lineaire de donnees, m§morjsee dans un flux (33) d'entr6e. En envoi de 
donnees. cet agent (211) de communication lit une succession lineaire de 
donnees dans un flux (42) de sortie et s6pare ces donnees pour Ies repartir en 
parametres (43) de reponses, compatibles avec Ies possibilites de transmission 

30 de la fonction (201) de reponse. 

L' agent (212) de serialisation gere Ies operations de conversion au 
niveau de Tobjet, en realisant la serialisation/deserialisation proprement dite. 
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Lors d'un envoi de donnees, done en serialisation, ragent(212) de 
serialisation, analyse la structure et le contenu d'un objet (41) iogiciel structure 
a transmettre, et realise un codage de cet objet sous la forme d'une succession 
lineaire de donnees, memorisee dans le flux (42) de sortie. Lors d'une 
5 reception de donnees, done en deserialisation, Tagent (212) de serialisation lit 
une succession lineaire de donnees dans le flux (33) d'entree. II analyse alors 
les donnees qui s'y trouvent et reconstitue Tobjet (34) Iogiciel structure qu'elles 
representent. 

10 La figure 3 represente un mode de realisation de T invention, ou la carte 

peut comporter plusieurs agents (221, 222, 223, 231) susceptibles d'etre 
destinataire pour le precede selon i' invention, ces agents pouvant §tre repartis 
dans une ou plusieurs applications (22, 23). De fagon a pouvoir traiter tous les 
echanges de donnees entre la carte (2) et Thote (1), le precede selon 

15 rinvention prevoit un agent (210) d* interposition par qui transitent tous les 
echanges de donnees structur6es entre la carte (2) et Thdte (1). 

Dans ce mode de realisation, I'agent (210) d' interposition regoiX toutes 
les donnees transmises a la carte, en lieu et place de I'application (22) ou 
I'agent (221) destinataire. et quel que soit ce destinataire. Cet agent (210) 

20 d' interposition va alors faire effectuer la concatenation des parametres (32) 
d'envoi par ragent(211) de communication, et faire ensuite deserialiser les 
donn6es(33) r6sultantes par I'agent (212) de serialisation, comme decrit ci- 
dessus, Une fois ces donnees reconstitutes en un objet (34) Iogiciel structure, 
c'est ce m§me agent (210) d' interposition qui va transmettre cet objet (34) 

25 structure a I'agent (221) Iogiciel qui §tait destinataire des donnees (32) lors de 
leur reception. Dans un mode de realisation (non represent^), les donnees (32) 

regues par- I'agent (21 0) d' interposition contiennent - une information 

representant 1' identification de ragent(221) destinataire. ou bien I'agent (210) 
d' interposition ajoute une telle infomiation a ces mSmes donnees (32) avant de 

30 les transmettre. L'objet (34) structure resultant de ia deserialisation est alors 
directement adresse par I'agent (212) de deserialisation ou par un agent de 
distribution (non represente). 




1 er dgpot 

30 



De la m§me fagon, ragent(210) d' interposition regoit toutes les 
donn^es (41) envoyees vers I'hdte par une application (22) ou un agent (221) 
emetteur. Get agent (210) d' interposition va alors faire s6rialiser ces donnees 
par I'agent (212) de serialisation en un flux (42) de sortie, puis faire concatener 
5 ce flux (42) de sortie par ragent(211) de communication, comme decrit ci- 
dessus. Les donnees obtenues seront alors envoy6es par la fonction (201) de 
reponse vers le terminal (1) a travers les moyens de communication (200, 100) 
sous la forme de parametres (43) de reponse. 

Dans un mode de realisation (non represente), I'agent (210) 

10 dMnterposition s'intercale au sein de la chaine (201, 211, 212, 221) de 
transmission et de conversion. En reception dans la carte (commande 
d'ecriture de la part de rhdte), Tagent (210) d' interposition dirige les donnees 
ou objets repus vers leur destinataire (221, 222, 223. 231) au sein de la carte.^ 
partir d* informations indues dans les donnees regues. En Emission depuis la 

15 carte (commande de lecture de la part de Thote), Tagent (210) d' interposition 
peut egalement etre pr6vu pour recevoir les donnees ou objets a imettre e$ 
leur affecte une information repr^sentant leur emetteur (221 . 222, 223, 231). 

Entre d'une part Thote (1), que ce soit le terminal lui-m§me ou un agent 
20 logiciel quelconque capable de g6rer ce temninal, et d'autre part un agent ou 
une application present sur la carte, on peut considerer que les ^changes 
d'infomiations se font done sur deux niveaux differents : au niveau de I'octet 
d'une part, et au niveau de Tobjet d'autre part. 

Au niveau des objets, les donnees organisees en objets logiciels 
25 structures a transmettre sont converties en un flux lin§aire de donnees et 
reciproquement. Cette etape de serialisation est celle qui gere la structure des 
objets et est realisee a IMnterieur de chaque plate-forme par Tagent de 
serialisation. 

Au niveau des octets, ou suites d'octets, les donnees agencies en 
30 simples flux Iin6aires sont transmises par bribes par Tintermediaire de la 
fonction de transmission, par exemple au fomiat APDU, qui est le seul moyen . 
d'echange d'informations entre la carte et le monde exterieur. Ces echanges 
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sont geres par les agents de communication hote et de la carte, qui 
communlquent entre eux en s'envoyant des parametres grace a cette fonction 
de transmission. 

De fagon a fournir a Tutilisateur des commandes transparentes, les 
5 diff6rents processus sont implementes dans une ou plusieurs classes, au 
moins une fonctionnant dans la carte et une fonctionnant dans le terminal ou 
rhote en general. Dans le langage Java®, le precede selon T invention peut 
ainsi fournir une classe « ObjectlOApplet » pour la carte et une classe 
« ObjectiOProxy » pour I'hote, par exemple selon la syntaxe suivante : 
10 class ObjectiOProxy { 

void- writeObject (Object o) ; 

Object readObject () ; 

} 

La classe « ObjectiOProxy » definissant une classe dans ThSte, 
15 fournissant a I'application de I'utilisateur les commandes d'ecriture d'objet 
« writeObject (Object) » et de lecture d'objet « readObject () ». 
class ObjectlOApplet { 

void process (Object o) ; 

void sendObject (Object o) ; 

20 } 

La classe « ObjectlOApplet » definissant une classe dans la carte, 
fournissant a I'application de Tutilisateur les commandes de traitement d'objet 
« process(Object) » et d'envoi d'objet « sendObjectQ » ; et 

La carte etant essentiellement passive, I'ensemble de ces conversions 
25 et transmissions se fait sur initiative de I'hote, par une instruction dans le code 
declenchant I'envoi d'une commande APDU. C'est cette commande qui va 
declencher I'operation de conversion demandee aupres de T agent concerne. 

Les commandes « process(Object) » et « sendObjectQ », lorsqu*elles 
sont executees dans le code de I'application de carte, ne declenchent done pas 
30 directement les operations de conversion correspondantes. La commande 
« sendObjectQ » va memoriser I'objet a envoyer dans une queue ou file de 
sortie, par exemple « qout », ou les objets a serialiser pour transmission seront 
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introduits par une commande d' introduction du type « qout.push(object) ». Lors 
du declenchement d*une operation de serialisation, ces objets a transmettre 
seront alors extraits de cette file de sortie dans Tordre oCi ils y ont ete introduits. 
De meme, la commande va extraire d'une file d'entree, par exemple 
5 . « qin », un objet serialise lors d'une operation precedente declenchee par 
rhote. Cette extraction se fera alors par une commande d'extraction du type 
« qln.popQ ». 

Les operations de lecture, ecriture, serialisation et deserialisation sont 
10 alors g^rees depuis Thote par la classe « ObjectlOProxy ». grace a des 
commandos transparentes a Tutilisateur. Ces commandes peuvent etre 
impl6mentees dans le code de cette classe, par exemple sous la forme 
suivante : 

- « card. Serialize out » : lance dans la carte la serialisation, comme decrit di- 
15 dessous, des objets a envoyer. Ces objets peuvent avoir ete memorises 

dans une file d'attente de sortie lors de I'execution d'une instructidn 
sendObjectQ par T application de la carte. 

- « card.Read » : lance dans la carte la lecture des donnees du flux 
de sortie et leur transmission vers ThSte, comme decrit ci-dessous. 

20 - « card.Write » : lance I'envoi de donnees vers la carte et leur 

6criture dans le flux d'entree, comme decrit ci-dessous. 

- <c card. Serialize In » : lance dans la carte la de-s6rialisation. comme 
decrit ci-dessous. des objets presents dans le flux d*entr6e. 

25 Dans le mode de realisation decrit ici, le flux de sortie et le flux d'entree 

de Ja carte sont memorises dans une m§me structure m6moire circulaire. 
D'autres modes de realisation sont bien sOr possibles utilisant une structure 
m6moire differente pour chaque flux, ou utilisant d'autres types de structures 
mfemoires. 

30 Une structure de memoire circulaire signifie en I'occurrence un 

ensemble d'emplacements de memoire se suivant, dont le premier 
emplacement est consider^ par le systeme comme 6tant immediatement a la 
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suite du dernier emplacement. C'est a dire qu'une succession lineaire de 
donnees peut etre memorisee dans une telle structure en commen^ant a 
nMmporte quel emplacement sans perdre sa continuite, du moment que la 
longueur de cette succession n'est pas superieure au nombre total 
5 d'emplacements, 

Le fait que les flux d'entree et de sortie partagent la meme structure 
circulaire consiste a memoriser les donnees qu'ils contiennent dans des zones 
differentes de cette meme structure circulaire, Les donnees contenues dans 
ces flux etant effac6es au fur et a mesure de ieur lecture, immedlatement ou 

10 lors d*une operation, la longueur et la position de ces deux flux varient ^ 
rinterieur de cette structure circulaire. Lorsque Tun des deux flux n'a plus de 
place pour memoriser de nouvelles donnees parce qu*il est bloque par les 
donnees non effacees de T autre flux, il suffit alors de traiter cet autre flux pour 
liberer la place qu'il occupe. 

15 Une telle structure circulaire permet de n'utiliser que peu de ressources 

m^moire tout en traitant des flux d^une longueur non determinee a Tavance. II 
suffit pour cela que les diff6rentes operations agissant sur ces deux flux 
sintercalent defa^on suffisamment equilibria. 

20 Au niveau des octets, depuis le flux de sortie d'une plate-forme vers le 

flux d' entree de r autre plate-fomie, et reciproquement, les echanges de 
donnees se font de la fapon suivante. 

Lorsque Thote veut obtenir des donnees se trouvant dans le flux de 
25 sortie de la carte, il emet une commande de lecture, par exemple selon la 
syntaxe Java® : « card. Read ». Cette commande lance une session de lecture, 
~ qui est typiquement divisee en plusieurs transactions, representant chaoune 
une iteration du processus. 

Pour initier la session de lecture, a travers son agent de communication 
30 et sa fonction de transmission, Vh&te emet une commande au fomnat APDU, 
assortie de parametres d'envoi (P1 et P2, soit un entier court) representant la 
longueur de donnees qu'il veut recevoir. A reception de cette commande, de 
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Tagent de communication de carte lit un premier bloc de donnfees dans le flux 
de sortie de la carte et !e transmet a la fonction de reponse de la carte. Ce 
premier bloc de donnees est alors retourne a I'hote en tant que donnees 
retournees (DataR) dans la reponse a la commande APDU. 
5 Chaque iteration successive du processus de lecture comprend alors 

renvoi par Thote d'une commande APDU assortie de parametres d'envoi (PI 
et P2, soit un entier court) representant la longueur des donnees deja regues. 
Une fois re9ue par I'agent de communication de carte, cette longueur fait office 
d' accuse de reception pour les envois precedents. Ainsi, I'agent de 

10 communication retourne comme donnees de reponse (DataR) les donnees du 
flux de sortie suivant immediatement la longueur indiquee par Thote. II est ^ 
noter que la lecture des donnees dans le flux de sortie se fait sans effacement 
de celles-ci, ce qui permet leur re-envoi en cas de besoin. On comprend bien 
qu'ainsi aucune donnee ne peut etre oubliee dans cette transmission. 

15 La session de lecture se termine lorsque la longueur demandee par 

rhote a §t6 bien regue, par arrdt des iterations de la part de I'hdte. La session 
peut egalement se terminer, ou s'interrompre, si T agent de communication de 
carte renvoie une donnee (par exemple un champ DataR de longueur nulle) ou 
un code (SW1 ou SW2) signifiant que toutes les donnees disponibles .dans le 

20 flux de sortie ont deja ete envoySes, Dans le cas d'un flux de sortie vide dans la 
carte, il incombe alors a Thote de declencher dans la carte une nouvelle 
operation de serialisation d'objets depuis la file de sortie « qout » de la carte 
vers le flux de sortie de la carte, pour que ce flux de sortie regoive de nouvelles 
donnees. 

25 

Lorsque I'hote veut envoyer a la carte des donnees se trouvant, il 6met 
une commande d'ecriture. par exemple selon la syntaxe Java® : 
« card .Write ». Cette commande lance une session d'ecriture, qui est 
typiquement divis&e en plusieurs transactions, representant chacune une 
30 iteration du processus. 

Pour initier la session d'ecriture, d travers son agent de communication 
et sa fonction de transmission, Thote 6met une commande au format APDU, 
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assortie de parametres d' envoi (P1 et P2, soit un entier court) representant la 
longueur des donnees qu'il veut transmettre. Le champ de donnees (DataT) de 
cette premiere commande APDU contient alors le premier groupe ou bloc de 
donnees a envoyer, ce bloc de donnees etant lu dans le flux de sortie de rh6te, 
5 A reception de cette commande, la fonction de r6ponse de la carte transmet ce 
premier bloc de donnees a I'agent de communication de carte. L'agent de 
communication de carte ecrit alors ce premier bloc de donnees dans le flux 
d'entree de la carte. 

Chaque iteration successive du processus d'ecriture comprend alors 

10 renvoi par Thote d'une commande APDU assortie de parametres d'envoi (PI 
et P2, soit un entier court) representant la longueur des donn§es deja 
envoyees. Le champ de donnees (DataT) de cette premiere commande APDU 
contient alors le groupe ou bloc de donnees suivant, lu dans le flux de sortie de 
rh6te. A reception de cette commande, la fonction de reponse de la carte 

15 transmet ces parametres et ce bloc de donnees a Tagent de communication de 
carte. U agent de communication de carte compare alors la longueur de 
donnees annohcees dans les parametres d'envoi (PI et P2) avec la longueur 
des donnees deja regues depuis le debut de la session d'ecriture. On 
comprend bien qu'ainsi aucune donnee ne peut &tre oubliee dans cette 

20 transmission. 

Si cette comparaison ne releve pas d'erreur, Tagent de communication 
de carte ecrit alors ce bloc de donnees dans le flux d'entree de la carte. En cas 
d'erreur. I'agent de communication retourne a Thote un code ou un indice 
indiquant une erreur et/ou representant la nature de cette erreur. Ce code ou 

25 indice peut §tre retourne a travers les parametres de reponse (SW1 et SW2) 
de la fonction de r6ponse, ou a travers le champ de donnees retourn§es 
(DataR) ou la longueur de ce champ, ou une combinaison de ces elements. 

La session d'ecriture se termine lorsque la longueur annonc6e par 
I'hfite a ete bien transmise, par arret des iterations de la part de Thfite. La 

30 session peut egalement se terminer, ou s'interrompre, si I'agent de 
communication de carte renvoie un code ou indice signifiant que le flux 
d'entree de la carte ne peut plus accueillir de nouvelles donn§es. II incombe 
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alors § I'hdte de d6clencher dans la carte une ou plusieurs operations 
permettant de liberer de I'espace dans la structure memoire qui contient ce flux 
d'entree. 

II peut s'agir de d^clencher dans la carte une nouvelle operation de 
5 deserialisation de donnees depuis le flux d'entree vers la file d'entree « qin » 
d'objets accessibles a T application carte, il peut s'agir egalement de 
declencher une nouvelle session de lecture pour recevoir des donnees 
contenues dans le flux de sortie de la carte, et liberer ainsi de Tespace dans la 
structure circulaire qui contient ces deux flux. 

10 

Au niveau des objets, les operations de serialisation et deserialisation 
se font entre les flux de donnees et les agents ou applications de la carte, et 
reciproquement, de la fagon suivante. 

15 Au sein de la carte, les objets sont deserialises depuis le flux (33)^ 

d'entr6e vers la file d'entree « qin » ou ils sont directement accessibles ^ 

■p ■ 

r instruction « Process(Object) », fournie par la classe « ObjectlOApplet » et 

utiiisee par Tagent ou Fapplication destinataire. 

Dans r implementation du precede selon Tinvention, loi^que rh6te veut 
20 declencher dans la carte une operation de deserialisation, il utilise une 

instruction, par exemple selon la syntaxe Java® « card. Serialize In ». 

Dans la figure 4 est illustr6e la deserialisation d'un objet (34) logiciel 

structure. S travers le decodage des donneesi du flux (32) d'entree 

correspondant a cet objet (34), et les operations de memorisation et de creation 
25 des composants de la structure de ce meme objet (34) structure, ou objet 

resultat. 

En lisant I'une aprSs Tautre les donnees memorisees en une 
succession lin§aire dans .le fiux(33) d'entree,J' agent (212) de serialisation 
interprete ces memes donn6es selon un codage determine et cree un 
30 objet (34) logiciel structure en fonction de cette interpretation, Dans cette 
succession de donnees memoris6e dans ce flux d'entree, certaines donnees 
peuvent avoir une valeur determinee qui sera interpretee comme marquant la 
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presence d'une balise de codage. Ce decodage peut se fairs par appel d'une 
methode d'allocation propre a chaque type d'objet structure a decoder, par 
exemple selon la syntaxe suivante : 

Typeobject: : decode (Object, InputStream) 
5 pour le decodage d'un objet « Object » de type « Typeobject » a partir 

du flux d'entree « Input Stream ». 

Ce codage comprend un jeu de balises ayant chacune une signification 
determinee, et con-espondant chacune a au moins une valeur specifique d'une 
donnee dans le flux d'entree. Ainsi, dans le flux d'entree, chaque donn6e d*une 
10 valeur correspondant a une de ces balises est interpret^e par Tagent de 
serialisation lors du processus de deserialisation. 

Selon les applications du precede selon Tinvention, Tagent (212) de 
serialisation pourra etre prevu pour reconnaitre plusieurs jeux de balises. ou 
des balises pouvant etre representees chacune par plusieurs valeurs 
15 differentes de donnees, sans sortlr de Tesprit de T invention. Une telle diversite 
pourra en particulier Stre utilisee pour permettre une compatibilite d*une nneme 
carte (2) ou type de carte avec plusieurs terminaux ou environnements botes 
differents. 

Dans le mode de realisation decrit ici. le codage connprend des balises 
20 de type « NULL », « NEW », « REF » et « DATA ». 

- Une balise NULL represente une absence de donnee, tout en occupant un 
emplacement dans la structure en cours de construction par T agent 
serialisation. 

- Une balise NEW indique a T agent de serialisation le debut de la description 
25 d'un nouvel objet, cet objet pouvant Stre soit un objet (34) logiciel structure 

resultant de la conversion, soit un objet, dit element composant une partie 
d'un tel objet (34) structure. 

- Une balise REF indique la designation d'un objet, un autre ou le mdme, en 
tant que source de la valeur de tout ou partie de Tobjet ou element en cours 

30 de description. II s'agit d'affecter une valeur par reference. 

- Une balise DATA indique que les donnees suivantes represented la valeur, 
ou contenu. de Tobjet ou element en cours de description. Ce contenu peut 
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§tre constitue de donn6es brutes repr6sentant directement una ou des 
valeurs a affecter a cat objet, ou inclure d'autres balises indiquant a 
nouveau des objets ou references definissantce contenu. 

Selon son type, una balise peut etre suivie d'une ou plusieurs donnees, 
5 . dont r interpretation sera determinee par la signification de cette meme balise. 

- Ainsi, a la lecture d'une balise NEW, Tagent de serialisation saura quMI doit 
interpreter la donnee sulvanta comme repr6sentant ie type du nouvel objet 
decrit. 

- De m§me, ^ la lecture d'une balise REF, I'agent de serialisation saura qu'il 
10 doit interpreter la donnee suivante comme representant un identiflant de 

I'objet designe comme source de cette valeur par reference. 

Dans Ie mode de realisation decrit ici, les balises comme les 
identificateurs de type et de r6f6rence sont codes sur un octet, mais il est 
evident que Ie precede selon T invention permet aussi bien d'utiliser d'autre.s 
15 codages, differents voire plus complexes ou explicites. en fonction des besoirts 
et des possibilites de Tenvironnement informatlque concerne. 

Au fur at a mesure da sa lecture des donnees du flux (32) d' entree, 
Tagent (212) de serialisation analyse la valeur de chacune de ces donnees, et 
effectue la creation puis Ie remplissage des objets ou Elements (340, 341, 342, 
20 343, 344) composant Tobjet (34) r^sultat. Cette lecture du flux (32) d'entree se 
repetera alors jusqu'a la reconstruction complete de T objet (34) represents par 
ce flux d'entre. Cette creation peut se faire par appel d'une m§thode 
d' allocation propre S chaque type d' objet, par exemple selon la syntaxe 
suivante : 

25 Typeobject: :inalloc() 

pour la creation ou allocation d'un objet de type « Typeobject » lors de 
la deserialisation. 

Du fait que de tels objets peuvent presenter una structure differente, la 
gestion de cette creation et de ce remplissage se font, directement ou non, par 
30 un agent (TMO. TM1, TM2) de controle de type specifique au type de I'objet a 
cr§er, par exemple un agent « type marshaller » du langage Java®. Cet agent 
de controle de type est specifique d un ou plusieurs types d'objets, et peut etre 
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ger6 par un agent (TMG) gestionnaire de types, par exemple un agent « type 
manager » du langage Java®. Get agent gestionnaire de types memorise en 
particulier les identifiants des differents types d'objets crees au cours du 
processus de deserialisation. Get agent (TMG) gestionnaire de types comprend 
5 egalement le code et les procedures, ou methodes, specifiques a ces differents 
types d'objets et utilises pour serialiser/deserialiser ces memes objets. G'est 
egalement lui qui gere la liste des objets et leurs allocations, ce qui permet de 
realiser de nouvelles allocations de reutiliser une allocation iibre pour creer un 
nouvel objet lors du decodage. 

10 De fagon typique, cet agent (TMG) gestionnaire de types comprend des 

informations sur tous les differents types d'objets pouvant etre geres dans la 
carte. Ges informations peuvent etre g6nerees par un bote, par exempie lors 
d'une phase de programmation de la carte. Elles sont alors transmises avec les 
classes (« applets ») utillsees par les applications, sous forme de code 

15 programme (« glue code ») s'ajoutant au code de I'agent (TMG) gestionnaire 
de types. 

Par r utilisation d'un tel agent gestionnaire de type, ainsi que d' agents 
de controle de type decrits ci-dessous, le precede selon r invention permet de 
20 gerer la serialisation et la deserialisation d'objets structures, de types de base 
ou de types construits, dans une plate-forme embarquee dont I'environnement 
de programmation, comme JavaCard par exemple, ne comporte pas un tel 
gestionnaire de type. 

25 Au cours du decodage, la creation d'un objet ou element correspond k 

une allocation de cet objet, c'est a dire la reservation d'un espace memoire 

determine- et r attribution de cet espace a cet- objet. Certains environnements 

embarques, et en particulier Javacard®, ne disposent pas d'outils logiciels 
permettant de rendre a nouveau disponible I'espace memoire auparavant 

30 occupe par un objet qui a ete supprime, comme par exemple un agent 
« garbage collector » du langage Java® classique. Lors de la creation d'un 
objet par Tagent (212) de serialisation, le precede selon IMnvention peut prevoir 
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la possibilite de realiser cette creation en allouant ^ cet objet un espace 
memoire precedemment occupe par un autre objet devenu inutile, par exemple 
de meme type que T objet a creer. II est ainsi possible d'une fois sur I' autre de 
reutiliser T espace mennofre de la carte, qui est une ressource precieuse dans 
5 de nombreux cas, car peu abondante. 



Dans Texemple illustre en figure 4, le flux (32) d'entree correspond a un 
objet (34) structure resultat dont la structure, ou graphe, peut etre decrite en 
langage Java® sous la forme suivante : 



Typel : {bool} 


class B {boolean bo ;} 


Type2 : Typel+{iiit, byte, TypeO} 


class X extends B { 
int i ; 
byte by ; 
Y y ; 

} ; 


TypeO : {Typel } 


class Y { B b ; } 



10 

Lors de la lecture du flux (33) d'entree, Tagent de serialisation lit tout 
d'abord une balise (321) NEW. II lit done la donn6e (322) suivante et memorise 
alors la demande de creation d'un objet de type 2. Conformement a cette 
balise (321) NEW d'identifiant 2, Tagent de serialisation va creer un nouvel 

15 objet. «x»(340) de classe X dans Texemple, par TintermSdiaire de Tagent 
(TM2) de contrdle de type correspondant a ce m§me type (Type2). S'agissant 
du debut de la description d'un objet resultat, ce nouvel objet sera T objet 
« racine » de Tarborescence du graphe de cet objet resultat 

Lors de cette creation, Tagent de serialisation va attribuer a Tobjet 

20 (340) cree un index (3402), cet index valant 0 dans Texemple. Cet index (3402) 
peut ainsi servir de reference a d'autres Elements ou parties d' elements lors de 
la construction de cet objet (34) resultat, et permettre de savoir si le contenu de 
cet element a ou non et6 rempli. 

U agent de serialisation va alors memoriser le type et T index de cet 

25 objet dans une structure memoire. dite pile de types (TYST). Cette pile de types 
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est une structure de type pile memoire, c'est a dire ou Ton peut memoriser 
(action dite « push » en anglais) des donnees Tune sur I'autre, et dont on ne 
peut lire et extraire (action dite « pop » en anglais) une donnee que lorsque 
ceux memorises apres lui ont deja ete extraits. Les donnees quittent cette pile 
5 dans Pordre inverse de celui ou elles y ont ete memorisees (« dernier entr6 
premier sorti ou « UFO » pour « Last In First Out »). 

U agent de serialisation va egalement memoriser le type de ce nouvel 
objet (340) ainsi que son index, comme correspondant a I'objet, dit objet (OBJ) 
en cours, qui sera rempli par les donnees suivantes du flux d'entree. 

10 

La balise suivante est une balise DATA suivie de deux donnees (324. 
325) brutes, qui ne sont pas des balises ni des identifiants. Ces deux donnees 
vont done etre memorisees dans I'objet (OBJ) en cours, c'est a dire x (340). en 
tant que valeur des elements (342, 343) suivants. Ces deux elements suivants 

15 etant respectivement de types entier (int) denomme «i» et octet (byte) 
denomme « by », ces elements vont done prendre respectivement les valeurs 
contenues dans ces deux donnees (324, 325) du flux d'entree. 

La balise suivante est une balise NEW, suivie d'une donnee indiquant 
un type 0. Cette sequence indique que I' element suivant de Tobjet « x » est un 

20 objet de type 0. L' agent de serialisation va done affeoter a cet objet (344) un 
index (3442), 1 dans I'exempie, et ajouter (« push ») Tindex et le type, a 
savoirO, de ce nouvel objet (344) sur la pile (TYST) de types. L' agent de 
serialisation va egalement faire creer un objet de type 0. dans I'exemple 
« y » (344) de type Y, par r agent (TMO) de controle de type correspondant au 

25 type 0. 

A travers 1' agent (TM2) de contr6le de type correspondant a Tobjet 

(OBJ) en cours, r agent de serialisation sait que cet objet (OBJ) en eours,- ^ 

savoir « x », n'est pas rempli completement. La balise suivante, une balise 
DATA suivie d'une donn§e (329) brute, sera done affect6e comme valeur de 
30 relement (341) suivant de Tobjet en cours, c'est d dire comme valeur de 
r Element denomm§ « bo » et de type booleen qui est le dernier element de 
r objet « X ». 
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Maintenant, a travers r agent (TM2) de controle de type correspondant 
a I'objet (OBJ) en cours, I'agent de serialisation sait que cet objet (OBJ) en 
cours, a savoir « x » (340), est completement rempii. LMndex (3402) de cet 
objet (340) rempii est done memorise dans la pile (OBJST) d'objets, avec 
ridentifiant de cet objet (340) au sein de la carte. Uagent de serialisation va 
alors clore le remplissage de I'objet en cours et depiler, ou extraire (« pop »), le 
type et Tindex memorises sur le dessus de la pile (PiTST) de types. Le dessus 
de la pile doit bien sur etre compris comme Templacement de cette pile 
accessible en premier. Le type et T index extrait de la pile de types, 0 et 
respectivement 1 dans Texemple, vont alors etre memorises comme 
correspondant a un nouvel objet (OBJ) en cours. 

La balise suivante est une balise DATA, qui indique done un 
remplissage de Tobjet en cours. c'est ^ dire « y ». Cette balise est suivie d'une 
balise (3211) REF et d'une donnee (3312), 0 dans Pexemple. L' agent dq 
serialisation va done affecter a I'objet « y » (344) une valeur par reference; 
c'est a dire une simple liaison avec la valeur de I'objet dont I'index (3402) est 
designe par cette reference (3212). L'objet « y » aura done une valeur definie 
comme faisant reference ^ I'objet « x » qui porte Hndex 0 au sein du processus 
de deserialisation. Cette liaison pourra alors etre definie dans I'objet (34) 
resultat par fa memorisation de ridentifiant de cet objet « x » dans la carte, cet 
identifiant etant lu dans la pile (OBJST) d'objets grace a cet index. 

Maintenant. a travers I'agent (TMO) de contrdfe de type correspondant 
a I'objet (OBJ) en cours, i'agent de serialisation sait que cet objet (OBJ) en 
cours. a savoir «y». est completement rempii. L' index (3442) de cet 
objet (344) rempii est done memorise dans la pile (OBJST) d'objets, avec 
ridentifiant de cet objet (344) au sein de la carte. L' agent de serialisation va 
alors clore ce remplissage et consulter la pile (TYST) de types. 

Du fait que la pile (TYST) de types est vide apres extraction du type de 
I'objet « y », c'est a dire qu'il n'y a plus de « types construits » a reconstituer, 
I'agent de serialisation conelut que I'objet (34) resultat est completement cree. 
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Dans une variante, la creation ou allocation d'un nouvel objet peut se 
faire a n'importe quel moment du processus de deserialisation, a partir de la 
lecture de la balise NEW indiquant ce nouvel objet. jusqu'au debut du 
remplissage de cet objet. 
5 Dans une variante, Tindex utilise lots de la deserialisation d'un objet est 

identique a Tidentifiant de I'objet dans la carte. 

Au sein de la carte, les objets sont serialises vers le flux (42) de sortie 
depuis la file de sortie «qout», qui est directement accessible a Tinstruction 
10 « SendObjectQ » fournie par la classe « ObjectlOApplet » et utilisee par Tagent 
ou Tapplication destinataire. 

Dans r implementation du precede selon Tinvention, lorsque Thote veut 
deciencher dans la carte une operation de serialisation, il utilise une instruction, 
par exemple selon la syntaxe Java® « card.Serialize Out ». 

15 

Dans la figure 5 est illustr6e [a serialisation d'un objet (41) logiciei 
structure, ou objet de depart, a travers Tanalyse des composants de la 
structure de ce meme objet (41) structure puis le codage sous forme de 
donnees memorisees dans le flux (42) de sortie correspondent a cet objet (41) 
20 de depart, 

Cette fonctionnalite de serialisation est impl^mentee dans une 
methode, c'est a dire une action ou procedure disponible pour un objet d'un 
type determine, et peut presenter la syntaxe Java® suivante : 
Typeobject: : (Object, OutputStream) 
25 etant une methode utilisee pour le codage d'un objet « Object » de type 

« Typeobject » vers le flux de sortie « OutputStream ». 

" - Typeobject : : getSuper (-)- - 

etant une methode utilis6e pour obtenir les informations concemant le 
type et les types construits d'un objet, lots du codage d'un Tobjet de type 
30 « Typeobject ». 

Les types de bases sont en general des types prevus et ger6s par 
renvironnement ou le langage de programmation, par opposition a des types, 
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dits types construits, definis comme une combinaison de plusieurs objets. Des 
types de base courants sent par exemple les types entier, booleen, octets 
(« integer », « boolean », « byte ») pour un environnement embarque, et 
egalement entier long, reel, reel long, caractere (« long », « real », « double ». 
5 « char ») pour des environnements plus complets. 



10 Pour cette serialisation, Tagent (212) de serialisation parcourt de fagon 

recursive Tensemble de la structure, ou du graphe, de I'objet (42) de depart a 
serialiser, et en analyse les elements (410, 412, 413, 414, 411), en 
commengant par Tobjet ou element « racine », « x » dans I'exemple. Le graphe 
de Tobjet (42) de depart presente dans Texemple est le meme que decrit cir 

15 deissus pour la figure 4. Pour chacun des elements du graphe presentant un 
type construit, Tagent de serialisation fait appel a un agent (TMO, TM1. TM2^ 
correspondant a ce meme type construit. • 
La description dans le flux (42) de sortie de Tobjet (41) de depart 
commence par I'ecriture d'une balise NEW suivie de Tidentifiant du type de 

20 I'element racine, Tobjet «x» de type 2 dans Texemple. Get objet racine est 
alors designe comme objet (OBJ) en cours. Par ailleurs, cet objet regoit un 
index, 0 dans Texemple, puis son type et son index sont introduits (action 
« push ») dans la pile (TYST) de types. 

La description se poursuit ensuite par Tecriture d'une balise DATA, 

25 suivie des donnees indiquant les vaieurs ou references correspondant au 
contenu de cet objet racine. Du fait que I'objet racine « x » contient un objet 
c<y»(414), qui est d'un type construit, la description de Tobjet racine 
comprendra une bafise NEW suivie du type de cet objet « y », « NEW 0 » dans 
Texempie, en lieu et place de la valeur de cet objet « y ». Lors de Tecriture de 

30 cette balise NEW, uh index lui est attribue, 1 dans Texemple. Puis i' index et le 
type de ce nouvel objet sont introduits (action « push ») dans la pile (T/ST) de 
types. 
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dits types construits, definis comme une combinaison de plusieurs objets. Des 
types de base courants sont par exemple las types entier. booleen, octets 
(« integer », « boolean », « byte ») pour un environnement embarque, et 
egalement entier long, reel, reel long, caractere (« long », « real ». « double ». 
5 « char ») pour des environnements plus complets. 

Pour cette serialisation. I'agent (212) de serialisation parcourt de fa?on 
recursive Tensemble de la structure, ou du graphe, de I'objet (41) de depart a 

10 serialiser, et en analyse les elements (410, 412. 413, 414, 411), en 
commengant par Tobjet ou 6Iement « racine », « x » dans Texemple. Le graphe 
de I'objet (41) de depart presente dans Texemple est le meme que decrit ci- 
dessus pour la figure 4. Pour chacun des elements du graphe presentant un 
type constrult. Tagent de serialisation fait appel a un agent (TMO, TM1 , TM2) 

15 correspondant a ce meme type construit. 

La description dans le flux (42) de sortie de robjet(41) de depart 
commence par I'ecriture tfune balise NEW suivie de Tidentifiant du type de 
I'element racine, Tobjet « x » de type 2 dans I'exemple. Get objet racine est 
alors d6signe comme objet (OBJ) en cours. Par ailleurs, cet objet regoit un 

20 index, 0 dans I'exemple, puis son type et son index sont introduits (action 
« push ») dans la pile (TYST) de types. 

La description se poursuit ensuite par I'ecriture d'une balise DATA, 
suivie des donnees indiquant les valeurs ou references correspondant au 
contenu de cet objet racine. Du fait que I'objet racine « x » contient un objet 

25 « y » (414), qui est d'un type construit, la description de Tobjet racine 
comprendra une balise NEW suivie du type de cet objet « y », « NEW 0 » dans 
I'exemple, en lieu et place de la vajeur de cet objet « y ». Lors de I'ecriture de 
cette balise NEW, un index (4142) lui est attribue, 1 dans I'exemple. Puis 
rindex et le type de ce nouvel objet sont introduits (action « push ») dans la 

30 pile (TYST) de types. 

Une fois terminie la description du contenu de I'objet (OBJ), c'est a 
dire I 'objet « x » (410), son index est memorise dans la pile (OBJST) d'objets 
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Une fois terminee la description du contenu de I'objet (OBJ), c'est a 
dire I *objet « x » (410), son index est memorise dans la pile (OBJST) d'objets 
avec ridentifiant de cet objet. Uagent de serialisation consulte alors la piles de 
types, en extrait (action « pop ») le type et I' index de r objet « y ». II memorise 
5 cet objet « y » comma nouvel objet (OBJ) en cours, et commence alors la 
description du contenu de cet objet « y ». Cet objet etant constitue d'une simple 
reference a T objet racine « x », les donnees ecrites dans le flux de sortie seront 
constituees d'une balise REF suivie d'une donnee valant I'index de I'objet a 
designer en reference, c'est a dire Tobjet « x » d'index 0 dans Texemple, 

10 Une fois terminee la description du contenu de cet objet en cours, c'est 

a dire Tobjet « y » (414), son index est memorise dans la pile (OBJST) d'objets 
avec ridentifiant de cet objet. Uagent de serialisation consulte alors la piles de 
types, en extrait (action « pop ») le type de I'objet « x » qui etaient memorises 
sous I'objet « y » dans cette pile de types. Du fait que Tindex de Tobjet « x » est 

15 deja memorise dans la pile (OBJST) d'objets, Tagent de serialisation sait que 
cet objet « x » a deja ete serialise, ou decrit, II consulte done a nouveau la pile 
de types, constate qu'elle est vide, et conclue done que T ensemble des 
Elements composants de I'objet (34) de depart ont ete entierement decrits dans 
le flux (42) de sortie. 

20 

Du fait de la recursivite de ces algorithmes, il est ainsi possible de 
realiser ces operations de serialisation et deserialisation a travers un code 
programme occupant suffisamment peu de place en m6moire pour pouvoir §tre 
memorise dans une plate-forme embarquee, par exemple une carte a puce ou 
25 un objet informatise portable au standard JavaCard. La concision de ces 
algorithmes permet egalement d'executer ces operations dans un processeur 
de faible puissance, comme ceux dont disposent de telles plates-formes 
embarqu6es. 

30 De fa9on ^ 6quilibrer les quantit§s de donn6es stockees sous forme 

interm6diaire, les differentes operations de lecture, ecriture, serialisation et 
d6s6rialisation demandees par Tapplication (11) hate peuvent §tre entrelacees 
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avec ridentifiant de cet objet. Uagent de serialisation consulte alors la piles de 
types, en extrait (action « pop ») le type et ('index de Tobjet « y ». 11 memorise 
cet objet « y » comme nouvel objet (OBJ) en cours, et commence alors la 
description du contenu de cet objet « y ». Cet objet etant constitue d'une simple 
5 r^f^pence (4141) a Tobjet racine « x », les donnees ecrites dans le flux de 
sortie seront constituees d'une balise REF suivie d*une donnee valant I'index 
de Tobjet a designer en reference, c'est a dire Tobjet « x » d'index 0 dans 
I'exemple. 

Une fois terminee la description du contenu de cet objet en cours, c'est 
10 a dire Tobjet « y » (414), son index est memorise dans la pile (OBJST) d'objets 
avec ridentifiant de cet objet.. L'agent de serialisation consulte alors la piles de 
types, en extrait (action « pop ») le type de Tobjet « x » qui etaient memorises 
sous !' objet « y » dans cette pile de types. Du fait que I'index de Tobjet <c x » est 
deja memorise dans la pile (OBJST) d'objets, Tagent de serialisation sait que 
15 cet objet « x » a d^j^ ete serialise, ou decrit. !l consulte done a nouveau la pile 
de types, constate qu'elle est vide, et conclue done que Tensemble des 
elements composants de I'objet (41 ) de depart ont ete entiferement decrits dans 
le flux (42) de sortie. 

20 Du fait de la recursivit6 de ces algorithmes, il est ainsi possible de 

realiser ces operations de serialisation et deserialisation a travers un code 
programme occupant suffisamment peu de place en memoire pour pouvoir etre 
memorise dans une plate-forme embarquee, par exemple une carte a puce ou 
un objet informatise portable au standard JavaCard. La concision de ces 

25 algorithmes permet egalement d'executer ces operations dans un processeur 
de faible puissance, comme ceux dont disposent de telles plates-formes 
embarquees. 

De fagon a equilibrer les quantites de donnees stock6es sous forme 
30 intermediaire, les differentes operations de lecture, Scriture, serialisation et 
deserialisation demandees par rapplicatlon (11) bote peuvent etre entrelacees 
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dans une ou plusieurs boucles de programme. Une telle boucle execute a 
chaque iteration une commande de chacune de ces operations, par exemple 
selon la syntaxe Java® suivante : 
Do 

5 Do card. Serialize out While (ok out) 

Do card. Read While (data read) 
While (data in) card. Write 
While (ok in) card . Serialize in 
Loop 

10 Dans cet exemple, les premiere et derniere lignes (« Do » et « Loop ») 

detennine la r§p6tition d'une boucle constituee des quatre lignes de code 
qu'elles encadrent. Une telle boucle peut bien sOr &tre combinee avec d'autres 
operations, et comporter diverses conditions d' interruption de la repetition. 

A rinterieur de ia boucle. la premiere ligne indique de declencher dans 

15 la carte une session de serialisation, vers le flux de sortie de la carte, des 
objets precedemment memorises dans la file de sortie « qout » par urie 
commande « SendObjectQ »- Cette session est ensuite repet6e tant qu'utSe 
condition d6nommee <c ok out» est remplie, par exemple tant qu'il y a des 
objets a envoyer dans la file « qout » et que le flux de sortie n'est pas plein. 

20 La deuxifeme ligne indique de declencher une session de lecture par 

rhSte des donnees contenues dans le flux de sortie de la carte. Cette session 
est ensuite rSpStde tant qu'une condition d^nommee « data read » est remplie, 
par exemple tant que des donnees sont repues depuis la carte. 

La troisieme ligne indique d'effectuer et rep6ter une session d'ecriture 

25 dans le flux d'entree de donnees venant de Thdte. Cette session ne s'effectue 
et ne se repete que si et tant qu'une condition denomm6e « data In » est 
remplie. Par exemple. tant qu'il y a des donnees a envoyer a la carte, et que le 
flux d'entree de la carte n'est pas plein. 

La quatrieme ligne indique d'effectuer et repeter une session de 

30 deserialisation des donnees contenues dans le flux d'entree de la carte, vers la 
file d'entree « qin » d*objets structures, d'oCi its sont extraits par une commande 
« process(Object) ». Cette session ne s'effectue et ne se repete que si et tant 
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qu'une condition denommee « ok in » est remplie. Par example, tant qu'il y a 
des donnees a deserialiser dans le flux d'entree de la carte. 

Dans le cas d'une carte passive, par exemple au standard JavaCard®, 
c'est typiquennent la fin de Toperation de serialisation d*un objet qui 
5 declenchera son traitement, par exemple en appelant automatiquement la 
methode « process(Object) ». 

II est a noter que seules les operations a effectuer du cote de la carte 
sent illustrees dans cet exemple. Les operations symetriques effectuees du 
10 cote de Thote peuvent etre realisees de fa$on similaire comme de fagon 
totalement differente, selon les ressources materielles et logicielles disponibles, 
sans sortir de Tesprit de T invention. 

Du fait que ces differentes operations complementaires sont 
15 entrelacees dans une boucle logicielle pouvant se repeter de fagon recursive, 
les differentes phases constituant le transfert d'un objet structure peuvent etre 
realisees en parallele, dans le cadre d'une seule execution ou d*une seule 
commande de transfert. En utilisant des flux de donnees memorises de fagon 
circulaire reutilisant indefiniment un meme espace memoire comme decrit plus 
20 haut, une meme commande peut declencher le transfert complet d*un objet 
structure sans limite de taille malgre les capacites limitees de la plate-forme 
embarquee. 

Lorsque Tensemble des operations de conversions decrites ci-dessus 
25 est Implemente. c*est ^ dire programme, dans une ou plusieurs procedures 

chargees dans I'hote et dans la plate-forme embarquee. Ces procedures 
peuvent aiors etre accessibles a futilisateur- a travers quelques commandes 

simples. 

Dans le mode de realisation decrit ici, applique au langage Java® et a 
30 I'environnement JavaCard®, le programmeur d'une application n'a ainsi qu'a 
utiliser ces quelques commandes simples pour realiser son application. Ces 
commandes realisent I'ensemble des operations interm6diaires de fagon 
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transparente pour Tutilisateur, c'est a dire sans qu'il ait besoin de se 
preoccuper du fonctionnement interne de leur mecanisme. 

A titre d'exemple, la classe « ObjectlOProxy », chargee dans la station 
de traitement ou le terminal hole, fournit ainsi les commandes « WriteObject() » 
5 et « ReadObjectO ». 

De meme, la classe « ObjectlOApplet », chargee dans la plate-forme 
embarquee, fournit les commandes « Process(Object) » et « SendObject() ». 
De fagon typique, la classe « ObjectlOApplet » implemente ces commandes 
par une technique connue de d'extension, c'est a dire par heritage de la classe 
10 « lOApplet » qui contient la methode « process(APDU) ». C'est a dire en 
ajoutant a cette methode du code programme qui vient s'ajouter a la methode 
initiate et modifier ou remplacer son fonctionnement tel que prevu dans la 
methode initiale. 

15 L'instruction « WriteObjectQ » est utilisee par Tutilisateur dans son 

application hote pour realiser renvoi d'un dbjet structure a ['application de la 
carte et y declencher un traifement. 

La methode « Process(Object) » est appelee automatiquement par la 
carte a la fin de la reception et de-serialisation d*un objet structure. Le contenu 

20 de cette methode est alors programme par Futilisateur dans la partie de son 
application chargee dans la plate-forme embarquee pour realiser les operations 
souhaitees a partir de cet objet. Cette methode est alors utilisee de fagon 
similaire a la commande standard « process(APDU) » existant en JavaCard® 
pour les seules donnees au format APDU. 

25 U instruction « SendObjectQ » est utilisee par I'utilisateur dans la partie 

de son application chargee dans la plate-forme embarquee, par exemple a 
Tinterieur du code de la methode « Process(Object) », pour preparer renvoi 
d'un ou plusieurs objets structures de la plate-forme embarquee vers Thote. 
Cette instruction est alors utilisee de fagon similaire a la commande standard 

30 «sendAPDU()» existant en JavaCard® pour les seules donnees au format 
APDU. 
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U instruction « ReadObjectQ » est utilisee par Tutilisateur dans son 
application hote pour realiser la reception depuis la plate-forme embarquee du 
ou des objets structures que rapplication de la carte a prepare dans ce but. 

On comprend bien qu'ainsi il est plus aise a un programmeur, realisant 
une application comportant une telle plate-forme embarquee, de transmettre 
des objets logiciels structures entre cette plate-forme embarquee et un bote ou 
terminal, meme si les moyens de communication de cette plate-forme 
embarquee ne sont aptes qu'a transmettre des donnees sous fomie d'octets 
ou d'entiers. 

Pour le programmeur d' une application embarquee, il peut §tre utile de 
disposer de quelques commandes simples permettant de r6aliser la 
desallocation d'un objet logiciel structure ou la remise a zero ou effacement de 
I'espace memoire correspondant. ainsi que la duplication d'un objet logiciel 
structure. Cela est particulierement vrai lorsque I'environnement de 
programmation de la plate-forme embarqu6e ne comprend pas d'outil logiciel 
(« garbage collector » en anglais) gerant la reutilisation de I'espace memoire 
deja alloue, par exemple dans Tenvironnement JavaCard®. 

Dans un mode de r6alisation du precede selon Tinvention, Tetape 
d' analyse de chacun des composants d'un objet logiciel structure au cours de 
sa serialisation peut effectuer selon diff6rentes options. Plusieurs de ces 
options peuvent Stre prevues dans T implementation d'une mSme commande 
de serialisation, chaque execution de cette commande etant assortie d'un 
parametre indiquant quelle option doit §tre utilisee. Ces differentes options 
peuvent egalement etre utilisees separement dans differentes implementations 
de la commande de s6rialisation, 

Dans une de ces options, lors de T analyse de chacun des composants 
d'un objet logiciel structure au cours de sa serialisation, Tagent (212) de 
serialisation effectue une d6sallocation de Tespace memoire contenant ce 
composant, ou marque ce meme composant comme pouvant etre reutilise pour 
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une nouvelle allocation. Ainsi, une serialisation selon cette option, dite 
serialisation destructive, effectue une conversion d'un objet structure suivie 
d'une liberation de son espace memoire. 

Dans un mode de realisation, le procede selon invention peut prevoir 
5 une option ou une commande reaiisant une telle serialisation destructive d'un 
objet structure memorise dans la carte, hors de toute transmission, par 
exemple dans T implementation de la classe « ObjectlOApplet ». On comprend 
bien qu' ainsi le procede selon ['invention permet a I'utilisateur de r6aliser 
ais6ment la reutilisation de i'espace memoire occupe par tout ou partie de 
10 certains des objets logiciels de son application. 

Dans un mode de realisation (non represente), le proc6d6 selon 
I' invention prevoit une option ou une commande reaiisant la deserialisation 
d'un objet structure en re-utilisant Tespace memoire dans la carte d'un objet 

15 structure precedemment detruit, comme decrit ci-dessus. Cette deserialisation 
est effectuee hors de toute transmission, a partir d'un flux de donnees 
contenant des donnees toutes identlques ou sans signification. Apres allocation 
et ecriture d'un tel objet, I'espace memoire r^utilise ne contiendra plus aucune 
donn^e provenant de T objet qui I'occupait precedemment Lorsque cette 

20 operation est implementee par exemple dans la classe « ObjectlOApplet », on 
comprend bien qu' ainsi le procede selon T invention permet a Tutilisateur de 
programmer aisement Teffacement complet d'un espace memoire 
correspondant d une allocation determin6e. 

25 Dans un mode de realisation (non represente), le procede selon 

r invention prevoit une option ou une commande reaiisant la serialisation d'un 
objet structure de depart vers une succession lineaire de donnees, hors de 
toute transmission. Cette m§me succession lineaire de donnees est alors 
deserialisee en un objet resultat identique a I'objet de depart mais utilisant un 

30 autre espace memoire. Lorsque cette operation est implementee par exemple 
dans la classe « ObjectlOApplet », on comprend bien qu'ainsi le procede selon 
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r invention permet a Tutilisateur de programmer aisement la duplication a 
ridentique d'un objet logiciel structure. 

II doit etre evident pour les personnes versees dans Tart que la 
5 presente invention permet des modes de realisation sous de nombreuses 
autres formes specifiques sans Teloigner du domaine d'application de 
invention comme revendique. Par consequent, les presents modes de 
realisation doivent etre consideres a titre d' illustration, mats peuvent etre 
modifies dans le domaine defini par la portee des revendications jointes, et 
10 invention ne doit pas etre limitee aux details donnes ci-dessus. 
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REVEMDICATIONS 

1. Precede de conversion de donnees utilisable par une station (2) 
informatique, dite plate-forme embarquee, comprenant un objet portable 
incluant au moins un processeur, des moyens de memorisation, et des moyens 

5 de communication aptes a 6changer des informations avec un terminal sous la 
forme d'une ou plusieurs successions lineaires de donnees, caracterise en ce 
qu'il comporte une etape de conversion d'un ensemble de donnees, dans un 
sens ou dans Tautre, entre d'une part un agencement en une succession 
lineaire de donnees et d'autre part un agencement structure d6crivant ou 
10 representant un ou plusieurs objets logiciels structures ou hierarchises suivant 
les crit6res d'un langage de programmation oriente objet. 

2. Proc6de selon la revendication pr6c6dente, caracterise en ce qu'il 
comporte des etapes de : 

- conversion, ou serialisation, d'un premier ensemble de donnees a 
15 transmettre comportant ou representant un ou plusieurs objets (31, :41) 
logiciels structures ou hierarchises suivant les criteres d'un langage de 
programmation orfente objet, depuis un agencement structure decrivant ou 
representant cet objet vers une succession lineaire de donnees 
representant ce premier ensemble de donnees ; 

20 - transmission de cette succession lineaire de donnees par des moyens (200, 
respectivement 100) de communication, depuis la plate-forme (2) 
embarqu§e vers au moins un hote (1), c*est d dire un terminal ou une 
station informatique reliee au terminal, ou de cet hdte(1) vers la plate- 
forme (2) embarquee ; 

25 - conversion apres transmission, ou de-serialisation, de cette succession 
lineaire de donnees vers un ensemble de donnees agence en un ou 
plusieurs objets (34, respectivement 44) logiciels structures reproduisant ou 
representant le premier ensemble de donnees. 
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3, Procede selon Tune des revendications precedentes, caracterise en 
ce que le terminal h6te(1) envoie des informations a la plate-forme (2) 
embarquee en utilisant un agent (101) logiciel, dit fonction de transmission, ces 
informations etant revues dans la plate-forme embarquee par une 
5 fonction (201) de reponse apte a declencher un traitement (2210) de ces 
donnees par au moins un agent (221) logiciel destinataire memorise dans la 
plate-forme embarquee et falsant partie d'au moins une application (21), le 
procede comprenant des etapes de : 

- reception, par un agent (211) de communication en lieu et place de 
10 {'agent (221) destinataire, d'un ensemble (32) de donnees regues par la 

fonction (201) de r6ponse a I'intention de cet agent logiciel destinataire, cet 
ensemble de donn6es etant agence en une succession lin6aire de 
donnees ; 

- conversion de cet ensemble de donnees en au moins un objet (34) logiciel. 
15 structure ou hierarchise suivant les criteres d'un langage de programmation 

oriente objet ; 

- transmission de cet objet (34) logiciel structure a Tagent (221) destinataire 
et declenchement d'un traitement (2210) en fonction de cet objet par cet 
agent destinataire. 

20 4. Procede selon Tune des revendications precedentes, caracterise en 

ce qu'il comporte des etapes de : 

- r6ception par la fonction (201) de reponse, en provenance de la 
fonction (101) de transmission de rhdte (1), d'au moins une donnee sous 
forme d'au moins un parametre (32)- d'envoi. et transmission de ce - - . 

25 parametre a un agent (211) de communication memorise ou execute dans 
la plate-fonne (2) embarqu6e ; 

- conversion, ou concatenation, par ragent(211) de communication d'au 
moins un parametre (32) d'envoi, transmis par Tagent (201) de r6ponse, en 



1 er depot 

54 



un ensemble de donnees agence en une succession lineaire de donnees et 
nnemorisation de ces donnees dans un flux (33) d*entree dans la plate- 
forme (2) embarquee ; 

conversion, ou de-s§rialisation, par un agent (212) de serialisation, 
memorise ou ex6cut6 dans la plate-forme (2) embarqu6e, d'au moins une 
partie des donnees memorisees dans ce flux (33) d'entree vers un 
ensemble de donnees comprenant ou representant au moins un objet (34) 
logiciel structure ; 

reception de cet objet (34) logiciel structure ou de ses references par 
Tagent (221) destinataire. 

5. Precede selon Tune des revendications precedentes, caracterise en 
qu'il comporte des etapes de : 

transmission d'un objet (41) logiciel structure ou de sa representation 
depuis un agent (221) logiciel falsant partie d'une application (22) executee 
ou memorisee dans une plate-forme (2) embarquee vers un agent (212) de 
serialisation execute ou memorise dans cette plate-forme embarquee ; 

conversion, ou serialisation, par cet agent (212) de serialisation de cet 
objet (41) logiciel structure vers un ensemble de donnees agence en une 
succession lineaire de donnees et memorisation de ces donnees dans un 
flux (42) de sortie dans la plate-forme embarquee ; 

conversion par un agent (211) de communication, memorise ou execute 
dans la plate-forme (2) embarquee, d'au moins une partie des donnees 
memorisees dans ce flux (42) de sortie vers un ensemble de 
parametres (43) de reponse aptes d etre transmis par la fonction (201) de 
reponse ; 

transmission de ces parametres (43) de r6ponse depuis la plate-forme (2) 
embarquee vers le terminal hote (1) par la fonction (201) de reponse, de sa 
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propre initiative ou en reponse a la fonction (101) de transmission du 
terminal hote (1). 

6. Proced§ salon Tune des revendicatlons precedentes, caracterise en 
ce que la succession lineaire de donn6es memoris^e dans le flux (33) d' entree 
5 ou le flux (42) de sortie represente un ou plusleurs objets (31. respectivement 
41) logiciels structures ou hlerarchises en utilisant une ou plusieurs donnees, 
dites ballses, d'une ou plusieurs valeurs determinees representant chacune 
une action determinee a effectuer lors de la deserialisation de cette succession 
lineaire de donn§es. 

10 7. Precede selon Tune des revendications precedentes, caracterise en 

ce qu'au moins une balise est definie comme representant une des actions 
suivantes : 

- ajout d'un nouvel element a la structure de Tobjet structure represente par 
la succession lineaire de donnees ; 

15 - reference a un element ou objet, dit objet source, en tant que source de la 
valeur de tout ou partie d'un element composant I'objet structure ; 

- indication que la ou les donn6es suivantes represented le contenu d'un 
element composant I'objet structure ; 

- Indication d'une absence de contenu d'un element composant Tobjet 
20 structure. 

8. Precede selon Tune des revendications precedentes, caract6rise en 
ce que ragent(212) de serialisation effectue la serialisation d'un objet (41) 

- structure, dit objet de depart, en un ensemble (42) Iln6aire de donnees suivant 

un precede, dit precede de serialisation, traitant au moins un des objets (410 a 

25 414). dits 6l§ments. composant la stmcture ou I'arborescence de cet objet (41) 
structure de depart, selon des etapes de : 
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- detection, par I' agent (212) de serialisation du type (4100) d'un element 
(410, 414), dit objet en cours, composant la structure ou Tarborescence de 
cet objet (41) structure ; 

- memorisation dans le flux (42) de sortie d'une donnee representant une 
5 balise indiquant Tajout d'un nouvel element, suivie d'une donnee 

representant le type (TYOBJ) de Tobjet en cours ; 

- memorisation dans le flux de sortie, a la suite des elements qui y sont deja 
presents, par un agent de serialisation de type (TMO. TM1, TM2) associe au 
type (TYOBJ) de T objet en cours, 

10 ■ soit d'au moins une donn6e (424, 425, 429) representant la valeur de 
tout ou partie (412, 413. 411) de 1' objet (41) structure ; 

" soit d'au moins une donn6e (421 1 , 4212) representant une balise (421 1) 
indiquant une reference a un objet (410) en tant que source de la valeur 
de tout ou partie (414) de Tobjet (41) structure, cette balise etant suivie 
15 d'une donn6e (4212) identifiant ledit objet (410) source ; : 

9. Precede selon Tune des revendications precedentes, caracterise en 
ce que le precede de serialisation effectue la conversion d'un objet (41) 
structure vers le flux (42) de sortie en memorisant au fur et a mesure de ses 
iterations le type de chaque objet en cours dans une pile (TYST) memoire. dite 

20 pile de types, dont les emplacements sont lus dans Tordre inverse de leur ordre 
de memorisation. 

10, Procede selon Tune des revendications precedentes, caracterise en 
ce que ragent(212) de serialisation effectue la deserialisation d'un ensemble 
lineaire de donnees en au moins un objet (34) structure resultat, suivant un 

25 precede, dit proc6de de deserialisation, traitant chacune des donnees 
memoris6es dans le flux (33) d' entree, selon des etapes de : 
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- detection, par ragent(212) de serialisation du type (4100) d'un element 
(410, 414), dit objet en cours. composant la structure ou Tarborescence de 
cet objet (41 ) structure ; 

5 - memorisation dans le flux (42) de sortie d'une donnee representant une 
balise indiquant i'ajout d'un nouvel element, suivie d'une donnee 
representant le type (TYOBJ) de Tobjet en cours ; 

- memorisation dans le flux de sortie, a la suite des elements qui y sont deja 
presents, par un agent de serialisation de type (TMG, TM1 , TM2) associ6 au 

10 type (TYOBJ) de Tobjet en cours, 

^ soit d'au moins une donnee representant la valeur de tout ou partie 
(412. 413, 411) de Tobjet (41) structure ; 

° soit d'au moins une donnee representant une balise indiquant une 
reference a un objet (410) en tant que source de la valeur de tout ou 
15 partie (414) de Tobjet (41) structure, cette balise etant suivie d'une 

donnee identifiant ledit objet (410) source ; 

9. Proc6de selon Tune des revendications precedentes, caracterise en 
ce que le precede de serialisation effectue la conversion d'un objet (41) 
structure vers le flux (42) de sortie en memorisant au fur et a mesure de ses 

20 iterations le type de chaque objet en cours dans une pile (TYST) m6moire, dite 
pile de types, dont les emplacements sont lus dans I'ordre inverse de leur ordre 
de memorisation, 

10. Procede selon Tune des revendications precedentes, caracterise en 

ce"que Tagent (212) de serialisation effectue la deserialisation d'un ensemble 

25 lineaire de donn§es en au moins un objet (34) structure resultat, suivant un 

procede, dit procede de deserialisation, traitant chacune des donnees 
memorisees dans le flux (33) d'entree, selon des etapes de : 
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detection, par I'agent (212) de serialisation du type (4100) d'un element (410, 
414), dit objet en cours, composant la structure ou Tarborescence de cet 
objet (41 ) structure ; 

- memorisation dans le flux (42) de sortie d'une donnee representant une 
5 balise indiquant Tajout d'un nouvel element, suivie d'une donnee 

representant le type (TYOBJ) de I'objet en cours ; 

- memorisation dans le flux de sortie, a la suite des elements qui y sont deja 
presents, par un agent de serialisation de type (TMO, TM1, TM2) associe au 
type (TYOBJ) de I'objet en cours, 

10 ■ soit d'au moins une donnee representant la valeur de tout ou partie 
(41 2, 41 3, 41 1 ) de Tobjet (41 ) structure ; ^ 

■ soit d'au moins une donnee representant une balise indiquant une 
reference a un objet (410) en tant que source de la valeur de tout ou 
partie (414) de I'objet (41) structure, cette balise etant suivie d'une 
15 donnee identifiant ledit objet (410) source ; 

9. Precede selon I'une des revendications prec§dentes, caracterise en 
ce que le procede de serialisation effectue la conversion d'un objet (41 ) 
structure vers le flux (42) de sortie en memorisant au fur et a mesure de ses 
iterations le type de chaque objet en cours dans une pile (TYST) memoire, dite 

20 pile de types, dont les emplacements sont lus dans Tordre inverse de leur ordre 
de memorisation. 

10. Procede selon I'une des revendications precedentes, caracterise en 
ce que I'agent (212) de serialisation effectue la deserialisation d'un ensemble 
lineaire de donnees en au moins un objet (34) structure resultat, suivant un 

25 procede, dit procede de deserialisation, traitant chacune des donnees 
memorisees dans le flux (33) d'entree, selon des etapes de : 
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- lecture par Tagent de serialisation d'au moins une donnee memorisee dans 
le flux d'entree a la suite des donnees precedemment traitees ; 

- analyse de cette donnee st realisation d'une action correspondant a cette 
donnee. 

5 11. Precede selon I'une des revendications precedentes, caracterise en 

ce que le precede de deserialisation comprend le rennplissage d'un element, dit 
objet en cours, c'est a dire raffectation d'une valeur directs ou indirecte a tout 
ou partie de cet objet en cours, cet element composant tout ou partie de la 
structure de I'objet (34) structure resultat. la fin du remplissage de Tobjet en 
1 0 cours declenchant 

- la lecture d'une donn6e (TYT2) representant un type d' objet memorise dans 
le prochain emplacement d'une structure de m6moire, dite pile (TYST) de 
types, et I'effacement de cette donn6e de cet emplacement ; 

- la memorisation, comme type (TYOBJ) d'un nouvel objet en cours, du type 
15 repr6sente par la donnee (TYT2) lue dans la pile de types. 

12. Precede selon Tune des revendications precedentes, caract6ris6 en 
ce que T objet (34) stmcturd cree par le proc6d6 de deserialisation est 
cons[d6re comme complet et transmis a ragent(221) logiciel ou 
rapplication (22) qui en est destinataire lorsque la pile (TYST) de types est 

20 vide. 

13. Precede selon I'une des revendications precedentes, caracterise en 
ce que Taction de deserialisation correspondant a une donnee (321, 326) 
representant une balise, dite balise « NEW », indiquant un nouvel element 
comprend des 6tapes de : 

25 - lecture d'au moins une donnee (322. 327) suivante dans le flux d'entree ; 
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- memorisation du type d'objet, represente par cette meme donnee (322, 
327) suivante, dans une pile memoire, dite pile (TYST) de types, a la suite 
des types qui y sent deja eventuellement memorises ; 

14. Precede selon I' une des revendications precedentes, caracterise en 
5 ce que la pile (TYDT) de types utilisee par le precede de deserialisation 

comprend une pile de type LIFO. c'est a dire dont les emplacements sont lus 
dans Tordre inverse de leur ordre de memorisation. 

15. Precede selon Tune des revendications precedentes, caracterise en 
ce que le precede de deserialisation comprend une etape de creation d'un 

10 element (410 a 414) composant la structure de I'objet (34) logiciel structure 
resultat, par allocation d'un nouvel espace memoire ou par reutilisation d'une 
allocation libre, cette creation etant realisee par un agent (TMO, TM1. YM2) de 
controle de type cerrespondant au type de Telement a creer. 

16. Proced§ selon Tune des revendications precedentes, caracterise en 
15 ce que Tetape de creation d'un §l§ment (410, 414) composant la structure de 

robjet(34) logiciel structure r6sultat a lieu entre P6tape de lecture d'une 
donnee (322, 327) indiquant la creation de cet element et ia premiere etape de 
remplissage de ce meme element. 

17. Procede selon Tune des revendications precedentes, caracterise en 
20 ce que Taction cerrespondant a une donnee (324, 325, 329), dite donnee 

simple, c'est a dire ne representant pas une balise, comprend une etape de 
memorisation de la valeur de cette donnee dans I'espace memoire alloue a 
Tobjet en cours. 

18. Precede selon Tune des revendications precedentes, caracterise en 
25 ce qu'au cours du procede de deserialisation, un index (4102) d'objet est 

attribue a au moins un element (410) composant la structure de Tobjet (34) 
structure resultat, cet index d'objet identifiant cet element de fagon unique et lui 
permettant d'etre designe ou reference par d'autres objets ou elements (414). 
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19. Procede selon Tune des revendications precedentes, caracterise en 
ce que faction correspondant a une donnee(3211) representant une balise, 
dite balise « REF », indiquant une reference comprend des etapes de : 

- lecture d'au moins une donnee (3212) suivante dans le flux (32) d'entree ; 

5 - memorisation dans I'espace (3441) memoire alloue a Tobjet (344) en cours. 
a la suite des donnees deja memorisees. d'une donnee designant un 
objet (340) comme source de la valeur de tout ou partie de Tobjet en cours, 
cet objet ou element (340) source etant identifie par iadite donnee (3212) 
suivante. 

10 20. Proced§ selon Tune des revendications precedentes, caracteris6 en 

ce que le remplissage de I* objet en cours est consider^ comme termine lorsque 
les donnees m6moris§es dans Tespace memoire qui lui est alloue 
correspondent a une longueur determinee. cette longueur etant lue en m6moire 
dans la carte (2) par un agent (TMO. TM1, TM2) de controle de type ou par un 

1 5 agent (TMG) gestionnaire de types memorise dans la plate-forme embarqu6e. 

21. Procede selon Tune des revendications precedentes, caracterise en 
ce que renvoi par la plate-forme embarquee (2), vers Thote (1), d'une 
succession (42) lineaire de donnees d'une longueur determinee, s'effectue 
selon un procede iteratif, dit de lecture de donnees, comprenant des etapes 
20 recursives de : 

- envoi par ThSte d'une commande de communication avec passage d'au 
moins un parametre d' envoi representant la longueur des donnees deja 
regues ; 

- reception par la plate-forme embarquee du parametre d'envoi et 
25 comparaison avec la succession lineaire de donnees a transmettre ; 



1 er depot 

60 



- reponse a la commande de communication par renvoi d'au moins un 
parametre (43) de retour representant la ou les donnees suivant 
immediatement les donnees deja regues par Thote ; 

- reception par I'hote du parametre (43) de retour de la commande de 
5 communication et memorisation des donnees qu'il represente a la suite des 

donnees dejS regues. 

22. Precede selon I'une des revendications precedentes, caracterise en 
ce que la reception par la plate-forme embarquee (2), en provenance de I'hote 
(1), d'une succession (43) lineaire de donnees d'une longueur determinee, 

10 s'effectue selon un precede iteratif. dit d'ecriture de donnees, comprenant des 
etapes recurs! ves de : 

- envoi par I'hote d'une commande de communication avec passage d'au 
moins un premier parametre (32) d'envol representant la ou les donnees 
suivant immediatement la partie deja transmise de la succession lineaire de 

15 donnees d transmettre, ainsi eventuellement qu'un deuxieme parametre 
d'envoi representant la position, dans la succession d transmettre, des 
donnees representees par le premier parametre d'envoi ou la longueur des 
donnees deja transmises ; 

- reception par la plate-forme embarqu6e du ou des parametres (32) d'envoi 
20 de la commande de communication ; 

- memorisation dans un flux (33) d'entree dans la plate-forme embarquee des 
donnees representees par le premier parametre (32) d'envoi ^ la suite des 
donnees deja regues. 

23. Precede selon Tune des revendications precedentes, caracterise en 
25 ce que le precede d'ecriture de donnees comprend en outre les etapes 

suivantes : 
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- comparaison par la plate-forme embarquee du deuxieme parametre d'envoi 
at comparaison avec la longueur des donnees deja re9ues ; 

- retour par la plate-forme embarquee d'au moins un parametre de reponse 
repr^sentant soit la longueur des donnees deja re9ues soil une donnee 

5 representant le resuitat de cette comparaison solt les deux ; 

24, Precede selon Tune des revendications precedentes, caracterise en 
ce qu'au moins deux des precedes de serialisation, deserialisation, lecture de 
donnees, ou ecriture de donnees sont effectues en parallele ou de fa9on 
entreiacee par repetition d'une etape comprenant I'execution successive d'au 

10 moins une etape de chacun de ces procedes. 

25. Proc§de selon Tune des revendications precedentes. caracterise en 
ce que le flux d' entree ou le flux de sortie ou tes deux sont memorises sous la 
forme de structures circulaires de m6moire. ces deux flux pouvant partager la 
meme structure circulaire. 

15 26. Proc6de selon Tune des revendications precedentes, caracterise en 

ce que la plate-forme embarquee comporte un environnement programmable 
apte a m6moriser et executer au moins une application realisee par un 
programmeur, la fonction de communication etant compatible avec le format 
« APDU » defini dans la nomie ISO 7816. 

20 27. Precede de conversion selon la revendication prec6dente, cecq des 

operations de deserialisation puis traitement d*un objet regu sont d§clenchees 
par la reception d*au moins une commande au format APDU comprenant au 
moins une donn6e indiquant la reception d'un objet structure. 

28. Precede selon Tune des revendications precedentes, caracterise en 
25 ce que la plate-forme embarquee comporte un environnement programmable 
compatible avec le standard JavaCard (marque deposee). 
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29. Procede selon Tune des revendications precedentes, caracteris§ en 
ce qu'au moins una des applications executees sur I'hote ou la plate-forme 
ennbarquee est programmee en langage Java®. 

30. Procede selon Tune des revendications precedentes, caracterise en 
5 ce que les precedes de lecture de donn6es, d'ecriture de donnees. de de- 
serialisation ou de serialisation sont mis en oeuvre a travers leur 
implementation dans au moins une classe m6moris6e dans I'hote ou dans la 
plate-forme embarquee, cette implementation comprenant au moins Tune des 
commandes suivantes : 

10 - une commande d'ecriture d'objet, effectuant la transmission d'un objet (31) 
structure a au moins un agent (221) de la plate-forme embarquee, par 
utilisation du procede de serialisation de cet objet, puis du proced6 
d'ecriture de donnees, puis du procede de de-seriaiisation ; 

- une commande de lecture d'objet. effectuant la lecture d'un objet (41) 
15 structure depuis au moins un agent (221) de la plate-forme embarquee, par 

utilisation du proced§ de serialisation puis du proced§ de lecture de 
donnees, puis du procede de deserialisation ; 

- une commande de desallocation d'un objet structure memorise dans la 
plate-forme embarquee, par utilisation du procede de serialisation, celui-ci 

20 comprenant en outre une etape de memorisation de la liberation ou 
desallocation de i'espace memoire alloue a chaque composant de cet objet, 
apres analyse de la structure de ce composant ; 

- une commande de nettoyage ou effacement d'un espace mSmoire Iib6r§ 
par un objet structure, par utilisation du proc6d6 de deserialisation pour 

25 creer un objet de contenu sans signification a partir d'une succession 
lineaire de donnees determinee ; 

- une commande de duplication d'un objet structure dit de depart, par 
utilisation du procede de serialisation, sans desallocation de cet objet de 
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depart, pour creer une succession lineaire de donnees representant ce 
meme objet, puis par utilisation du procede de deserialisation a partir de 
cette succession lineaire de donnees pour creer un autre objet structure de 
contenu identique a Tobjet de depart. 

5 31, Procede selon la revendication precedente. cecq le langage de 

programmation de la plate-forme ennbarquee comporte une premiere classe 
(lOApplet) decrivant une methode abstraite ProcessAPDU, langant lors de la 
reception d*un message APDU, un traitement parametrable dans T application ; 
le code programme realisant les operations de deserialisation dans la plate- 

10 forme embarqu6e etant memorise dans la plate-forme embarquee, en tant 
qu' implementation de cette methode abstraite ProcessAPDU, dans une 
deuxi^me classe (ObjectlOApplet) heritant de la premiere classe (lOApplet). ce 
meme code programme faisant appel a une m6thode ProcessObject elle-m§me 
decrite comme une methode abstraite dans cette meme classe 

1 5 (ObjectlOApplet) d' implementation . 

32. Procede selon la revendication (Javacard), cecq le langage de 
programmation de la plate-forme embarquee comporte une premiere classe 
(lOApplet) decrivant une methode SendAPDU emettant vers Thote un message 
au format APDU ; le code programme realisant les operations de serialisation 

20 dans la plate-forme embarquee etant memorise, en tant quMmplementation 
d'au moins une methode SendObject faisant appel a la methode SendAPDU, 
dans une deuxieme classe (ObjectlOApplet) de carte heritant de la classe 
(lOApplet). 

33. Precede selon Tune des revendications prec6dentes, caracterise en 
25... -ce qu'il est utilise pour la. communication -entre au- moins- un agent logiciel, dit - 

agent de carte, memorise ou execute dans la plate-forme embarquee et au 
moins un agent logiciel, dit agent proxy de moteur de carte memorise ou 
execute dans au moins un hdte appartenant a un reseau informatique 
communiquant par messages asynchrones selon une infrastructure logicielle de 
30 type AAA-MOM, cet agent proxy de moteur de carte servant d'intermediaire d 
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Tagent de carte dans ses communications avec d'autres agents de ce reseau, 
ces agents fonctionnant selon ies specifications de cette Infrastructure logicielle 
et appartenant ^ au moins une application distribuee. 

34, Systdme informatique comprenant une station (2) informatique, dite 
5 plate-forme embarquee, comprenant un objet portable incluant au moins un 
processeur, des moyens de memorisation, et des moyens de communication 
aptes a echanger des informations avec un terminal sous la forme d'une ou 
plusleurs successions lin§aires de donnees, caracterise en ce que la plate- 
forme comprend un agent (212) de serialisation apte a effectuer une etape de 
10 conversion d'un ensemble de donnfees. dans un sens ou dans T autre, entre 
d'une part un agencement en une succession lineaire de donnees et d'autre 
part un agencement structure decrivant ou reprfesentant un ou plusieurs objets 
loglciels structures ou hierarchises suivant Ies criteres d'un langage de 
programmation oriente objet. 

15 35. Systeme selon la revendication precedente, caracterise en ce que 

la plate-forme embarquee (2) comprend un agent (21 1) de communication apte 
a : 

- recevoir en lieu et place de Tagent (221) destinataire un ensemble (32) de 
donnees regues par la fonction (201) de reponse d Tintention d'un agent 

20 (221) logiciel destinataire memorise dans la plate-forme embarquee. cet 
ensemble de donnees etant agenc6 en une ou plusieurs successions 
lineaires de donnees ; 

- convertir cet ensemble de donnees en au moins un objet (34) logiciel, 
structure ou hierarchise suivant les criteres d'un langage de programmation 

25 oriente objet ; 

- transmettre cet objet (34) logiciel structure a ragent(221) destinataire et 
declencher un traitement (2210) en fonction de cet objet par cet agent (221) 
destinataire. 
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36. Systeme selon I'une des revendications precedentes, caracterise 
en ce que la succession lineaire de donnees representant un objet logiciel 
structure est memorisee dans la plate-forme embarquee dans un flux d'entree 
ou un flux de sortie, la plate-forme embarquee comportant un agent (ogiciel dit 
5 agent (212) de serialisation apte a creer dans la plate-forme embarquee le ou 
les objets structures representes par le flux d'entree, c'est a dire a deserialiser 
ces objets structures, ou a ecrire dans le flux de sortie des donnees 
representant le ou les objets structures a transmettre, c'est a dire a serialiser 
ces objets structures. 

10 37. Systeme selon Tune des revendications pr6cedentes, caracterise 

en ce que le flux d'entree ou le flux de sortie sont memorises sous la forme 
d'une ou plusieurs stnjctures circulaires de m6moire. 

38. Systeme selon I'une des revendications precedentes, caracterise 
en ce que I'agent (212) de serialisation utilise une pile memoire, dite pile de 
15 types, pour memoriser le type d'au moins un objet composant tout ou partie de 
la structure d'un objet structure a serialiser ou deserialiser, cette pile de type 
comportant des emplacements m^moires qui ne sont chacun accessibles 
qu'apres que les emplacements memorises plus recemment aient ete lus et 
effaces. 

20 39. Systeme selon Tune des revendications precedentes, caracteris6 
en ce que les donnees contenues dans les flux d'entree ou de sortie 
representent un ou plusieurs objets structures en utflisant un codage 
comprenant un jeu de balises. ces balises repr6sentant chacune une action 
determinee a effectuer lors de la deserialisation de cette succession Iin6aire de 
...25. ...jdonnees.. _ _ 



40. Systeme selon Tune des revendications precedentes, caracterise 
en ce qu'au moins une balise est definie comme representant une des actions 
sulvantes : 
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- ajout d'un nouve! element a la structure de I'objet structure represents par 
la succession lineaire de donnees ; 

- reference a un elennent ou objet. dit objet source, en tant que source de la 
valeur de tout ou partie d*un element composant Tobjet structure ; 

5 - indication que la ou les donnees. suivantes representent le contenu d*un 
element composant I'objet structure ; 

- indication d'une absence de contenu d'un element composant Tobjet 
structure. 

41. Systeme selon Tune des revendications precedentes, caractSrise 
10 en ce que la plate-forme embarquee comprend un objet portable fonctionnant 

selon la norme IS07816 et utilisant des commandes au format APDU. 

42. Systeme selon Tune des revendications precedentes, caracterise 
en ce qu'au moins un agent ou application memorise dans la plate-forme 
embarquee est programme en langage Java®, la plate-forme ernbarquee 

15 comportant un environnement informatique selon le standard JavaCard®. 

43. Systdme selon Tune des revendications precedentes, caract6ris6 
eh ce quMI comporte dans Thote ou dans la plate-forme embarqu6e, ou les 
deux, au moins une classe logicielle implementant au moins Tune des 
commandes suivantes : 

20 - une commande d'ecriture d'objet, effectuant la transmission d'un objet (31) 
structure a au moins un agent (221) de la carte, par serialisation de cet objet 
structure en un flux de donnees dans I' bote, puis envoi de ce flux de 
donnees dans la plate-forme embarquee, puis de-serialisation de ce flux de 
donnees en un objet structure dans la plate-forme embarquee ; 

25 - une commande de lecture d'objet, effectuant la lecture d'un objet (41) 
structure depuis au moins un agent (221) de la carte, par serialisation de cet 
objet structure en un flux de donnees dans la plate-forme embarqu6e, puis 
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reception depuis la plate-forme embarquee de ce flux de donnees, puis 
deserialisation de ce flux de donnees en un objet structure dans Thote ; 

- une commande de desallocation d'un objet structure nnemorise dans la 
plate-forme embarquee, par une serialisation de cet objet selon une option 

5 comprenant une liberation ou desallocation de Tespace memoire alloue a 
chaque composant de cet objet, apres analyse de la structure de ce 
composant ; 

- une commande de nettoyage ou effacement d'un espace memoire libere 
par un objet structure dans la plate-forme embarquee, par deserialisation 

10 d'une succession lineaire de donnees determinee pour creer un objet de 
contenu sans signification ; 

- une commande de duplication dans la plate-forme embarquee d'un objet 
structure dit de depart, par serialisation en une succession lin§aire de 
donnees representant ce m§me objet, sans desallocation de cet objet de 

15 depart, puis par deserialisation § partir de cette succession lineaire de 
donnees en un autre objet structure de contenu identfque a I'objet de 
depart. 

44. Systeme selon Tune des revendications precedentes, caracterise 
en ce que la plate-forme embarquee communique au moins un hote 

20 appartenant S un reseau infomnatique communiquant par messages 
asynchrones selon une infrastructure logicielle de type AAA-MOM, cet hote 
comprenant un agent logiciel, dit agent proxy de moteur de carte, apte a gerer 
les communications de cette plate-forme embarquee avec d'autres agents de 
ce reseau. ces agents fonctionnant selon les specifications de cette 

25 infrasVucture logicielle ^e^^ une application "di'stri 
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